lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Removing branch_5x shortly
Date Sat, 20 Feb 2016 20:23:14 GMT
bq. So what exactly was the old informal guidance that determined when
branch_4x was removed>?

Interesting, you are right. I don't recall that at all. There is probably a
JIRA or email thread needle out there with the discussion. Silence and
absence is consensus. I may even have been for the idea at the time, no
recollection. I assume we made some decision at some point to clean out all
the old branches.

If we did not have the technical issues Dawid is concerned about, I would
say, removing really old dead dev branches doesn't bother me much. But it
seems we should always at least keep the last branch.

But then removing it doesn't seem to make much sense with Git anyway. And
it's not like we release so fast that the number of branches is
overwhelming.

- Mark

On Sat, Feb 20, 2016 at 3:08 PM Jack Krupansky <jack.krupansky@gmail.com>
wrote:

> +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
> release".
>
> -- Jack Krupansky
>
> On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <uwe@thetaphi.de> 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 <
>> dawid.weiss@gmail.com>:
>>>
>>>  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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>> --
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, 28213 Bremen
>> http://www.thetaphi.de
>>
>
> --
- Mark
about.me/markrmiller

Mime
View raw message