lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Krupansky <>
Subject Re: Removing branch_5x shortly
Date Sat, 20 Feb 2016 20:08:27 GMT
+1 for managing git branches the same way as branches were managed in svn
(modulo any specific technical differences of git vs. svn). I see only
branch_5x in svn right now - when in the staging of release 5.0 was
branch_4x deleted?

Looking at the official ReleaseToDo wiki, I don't actually see any process
for removing old branches. So what exactly wss the old informal guidance
that determined when branch_4x was removed>?

BTW, when branchng for a new release, I see this confusing statement: "For
the first release in a minor release series - i.e. X.Y.0 - create a minor
release branch off the current major version branch, e.g. for minor release
5.5." I mean, shouldn't there be two separate statements, first the
creation of the stable branch on a major release, and second the creation
of a point/bugfix branch from the stable branch on a minor release? Or have
explicit sections for "Major release", "Minor release", and "Bugfix

-- Jack Krupansky

On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <> wrote:

> Hi,
> Let's keep the branch. The other ones from 3 and 4 are also still there.
> If anybody commits, who cares? If we don't release, it's just useless work.
> If we want to nuke branch, do the same for previous ones.
> Uwe
> Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss <
>>  Can't we tag it and then delete the branch?
>> Any reference. So yes, sure you can. But this doesn't really address
>> the second part of my e-mail -- people would still have to issue:
>> git remote prune origin
>> and I don't want to fight Uwe over supposedly magical git commands :)
>>  if infra let's us put in any git hooks and protect branches from there.
>> Yes, this would be another option (but it requires admin-side tweaks).
>>  I'm not convinced we need a new strategy just because we are on git though.
>>>  We generally don't decide
>>> we won't do a release, someone volunteers to put
>>>  one together when something prompts it. I don't remember protecting branches
>>>  in SVN and so I wonder if we need to now?
>> Exactly. We really don't need to do anything other than just agree to
>> not commit there... that's part of the reason I wanted more "semantic"
>> names for branches -- they're kind of hard to eradicate once created
>> in public.
>> Anyway, as for branch_5x -- no need to protect anything, really. If
>> somebody DOES commit something (by accident or otherwise) we can
>> always revert those commits (or even force the reference to what it
>> was before the mistake, effectively undoing the change).
>> D.
>> ------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen

View raw message