You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2016/02/20 17:52:20 UTC

Removing branch_5x shortly

Please don't back-port anything to branch_5x: I'd like to remove it,
i.e. any back-ports from master should be only bug fixes and go to
branch_5_5's next bug fix release (5.5.1) instead.

I see some recent commits for Solr here ... if these are really
bug-fixes, please re-push to 5.5 branch instead.

The current tip of branch_5x is
e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
how git will GC this once I remove branch_5x.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
I think it fits a lot more with how we work to add some documentation to
the release wiki and or elsewhere about changing index format after the
next major release, and that the release manager should ping the list and
scan changes for potential violations in such release situations.

That seems much more in line with our practices and let's us keep the
stable line alive. If we cannot do that, all this crazy effort we put into
two simultaneous branches has even less value.

- Mark

On Sat, Feb 20, 2016 at 3:47 PM Michael McCandless <
lucene@mikemccandless.com> wrote:

> On Sat, Feb 20, 2016 at 1:32 PM, Yonik Seeley <ys...@gmail.com> wrote:
> > On Sat, Feb 20, 2016 at 12:46 PM, Michael McCandless
> > <lu...@mikemccandless.com> wrote:
> >> We are precluding it: 5.5.x is the last feature release before 6.0.0.
> >>
> >> I don't think we should do another 5.x feature release after 6.0.0 is
> out.
> >
> > Can't that be decided at some point in the future (i.e. if someone
> > wants to go through the work of backporting some features to 5x and
> > making a 5.6)?
> > Or is there a technical reason (like something to do with the versions
> > stored in the index) why that wouldn't be feasible?
>
> That's exactly it.
>
> In a 5.6 release we are normally free to improve the index format, as
> long as the change is backwards compatible (5.6 can still read all 4.x
> and 5.x indices).
>
> But if we do that then the (already released) 6.0 won't be able to
> read 5.6 indices, which I think would be very bad.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

Posted by Yonik Seeley <ys...@gmail.com>.
On Sat, Feb 20, 2016 at 3:42 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> But if we do that then the (already released) 6.0 won't be able to
> read 5.6 indices, which I think would be very bad.

For sure, forward compatibility would need to apply.
That still leaves open a wide range of features at both the Lucene and
Solr level though.  If someone wanted to release a 5.6 that wasn't
forward compatible (to the degree that 5.5 will be) that would be a
reason to vote against it.

If, on the other hand, a future 5.6 would not be forward compatible by
the mere fact that it's called "5.6" then that should be fixed now,
before 6.0 is released.  We shouldn't be forced to preclude additional
5.x releases.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Michael McCandless <lu...@mikemccandless.com>.
On Sat, Feb 20, 2016 at 1:32 PM, Yonik Seeley <ys...@gmail.com> wrote:
> On Sat, Feb 20, 2016 at 12:46 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>> We are precluding it: 5.5.x is the last feature release before 6.0.0.
>>
>> I don't think we should do another 5.x feature release after 6.0.0 is out.
>
> Can't that be decided at some point in the future (i.e. if someone
> wants to go through the work of backporting some features to 5x and
> making a 5.6)?
> Or is there a technical reason (like something to do with the versions
> stored in the index) why that wouldn't be feasible?

That's exactly it.

In a 5.6 release we are normally free to improve the index format, as
long as the change is backwards compatible (5.6 can still read all 4.x
and 5.x indices).

But if we do that then the (already released) 6.0 won't be able to
read 5.6 indices, which I think would be very bad.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Yonik Seeley <ys...@gmail.com>.
On Sat, Feb 20, 2016 at 12:46 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> We are precluding it: 5.5.x is the last feature release before 6.0.0.
>
> I don't think we should do another 5.x feature release after 6.0.0 is out.

Can't that be decided at some point in the future (i.e. if someone
wants to go through the work of backporting some features to 5x and
making a 5.6)?
Or is there a technical reason (like something to do with the versions
stored in the index) why that wouldn't be feasible?

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Michael McCandless <lu...@mikemccandless.com>.
We are precluding it: 5.5.x is the last feature release before 6.0.0.

I don't think we should do another 5.x feature release after 6.0.0 is out.

Mike McCandless

http://blog.mikemccandless.com

On Sat, Feb 20, 2016 at 12:30 PM, Yonik Seeley <ys...@gmail.com> wrote:
> Why are we precluding a future 5.6 release (or are we)?
>
> -Yonik
>
> On Sat, Feb 20, 2016 at 11:52 AM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>> Please don't back-port anything to branch_5x: I'd like to remove it,
>> i.e. any back-ports from master should be only bug fixes and go to
>> branch_5_5's next bug fix release (5.5.1) instead.
>>
>> I see some recent commits for Solr here ... if these are really
>> bug-fixes, please re-push to 5.5 branch instead.
>>
>> The current tip of branch_5x is
>> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
>> how git will GC this once I remove branch_5x.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Yonik Seeley <ys...@gmail.com>.
Why are we precluding a future 5.6 release (or are we)?

-Yonik

On Sat, Feb 20, 2016 at 11:52 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> Please don't back-port anything to branch_5x: I'd like to remove it,
> i.e. any back-ports from master should be only bug fixes and go to
> branch_5_5's next bug fix release (5.5.1) instead.
>
> I see some recent commits for Solr here ... if these are really
> bug-fixes, please re-push to 5.5 branch instead.
>
> The current tip of branch_5x is
> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
> how git will GC this once I remove branch_5x.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
On Tue, Feb 23, 2016 at 11:37 AM Michael McCandless <
lucene@mikemccandless.com> wrote:

>
> Fourth, by releasing 6.0, shortly, we (Lucene/Solr devs) are declaring
> to our users that we intend future new features to go into 6.1, 6.2,
> etc., the new stable branch.  I don't think we want / can afford to
> have two stable branches at once.
>

That is just one opinion, and when we talked about moving to two branches,
many other opions were shared.

If 6x is the current unstable branch, 6.0 is not stable. 6.1 is not stable.

5.5 is the stable release. It's been around, it's had the bug fixes and use
and hardening. 6.x has not had the use and hardening as 5.x and is supposed
to have to scary changes!

It's just as valid an opinion that a committer that wants to backport
features that make sense for a 5.6, a stable 5.x release, rather then just
have it in the *unstable* 6.0 release for the early adopters.

- Mark
-- 
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

Posted by Shai Erera <se...@gmail.com>.
I agree. No one says anything about deliberately introducing new features
in a 5.6. At least from my POV, I'd like to be able to not take down my
Solr cluster when upgrading to 6.0, so if any work needs to happen on the
5x branch (and maybe also on the 6x branch) to make that happen, I'll
gladly do it. Even if it means that eventually I will only be able to
upgrade from 5.5 to 6.1 and have to skip all other releases.

I'm pretty sure that's the spirit of changes that will go into future 5x
releases (and I don't think it's gonna be a loong future after 6.0 is out)
-- definitely not index format changes.

Shai

On Tue, Feb 23, 2016 at 8:28 PM Mark Miller <ma...@gmail.com> wrote:

> It's just an example though. Beyond simple features and improvements,
> there are also lots of things we do under Other and Optimizations that we
> would not not necessarily consider for a bug fix release (higher bar), but
> that would be in a 5.6 release. A jetty point release update for example.
>
> - Mark
>
> On Tue, Feb 23, 2016 at 1:10 PM Nicholas Knize <nk...@gmail.com> wrote:
>
>> > Things that help users migrate from 5x to 6x that we perhaps missed out.
>>
>> This may be semantics but these sound to me like bugs? Not features?
>>
>>
>> On Tuesday, February 23, 2016, Anshum Gupta <an...@anshumgupta.net>
>> wrote:
>>
>>> My thoughts exactly.
>>>
>>> The features that go into a possible 5.6 or 5.7 release would be stuff
>>> that is unrelated to index format. Things that help users migrate from 5x
>>> to 6x that we perhaps missed out. I'm just saying there's a real valid
>>> possibility of such a release.
>>>
>>>
>>> On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller <ma...@gmail.com>
>>> wrote:
>>>
>>>> I just want to point out: just like the previous line of bug fix
>>>> releases dies down heavily, so would the feature backports. They will
>>>> likely be simple useful things rather than crazy complicated hard things.
>>>> There probably won't be that many, just like the bug fix releases. Let's
>>>> not pretend it's going to end up like an active branch with devs always
>>>> wondering if the new codec they are slamming in is going to mess things up.
>>>>
>>>> If there is any demand for this, it's going to be by people on 5x for
>>>> stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
>>>> or may not be any better. Upgrading a major release can be quite disturbing
>>>> and many users take a long, long time to do it.
>>>>
>>>> A 5.6, 5.7 would only be more stable. Fewer and simpler backports than
>>>> our two main branches. Users can simply gobble them up, rather than choke
>>>> them down like a major release. Useful features can be found that may not
>>>> affect index format.
>>>>
>>>> Anyway, if there ends up being demand, I'll certainly be one of the
>>>> 3 +1's needed.
>>>>
>>>> - Mark
>>>>
>>>> On Tue, Feb 23, 2016 at 12:18 PM Mark Miller <ma...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <uw...@thetaphi.de>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> To me it is quite clear that once we released 6.0, there is
>>>>>> technically no possibility to release a brand new 5.6 Feature-Release! The
>>>>>> main reason: 6.0 (if released before 5.6) will not be able to read indexes
>>>>>> of 5.6 (because it does not know about the format at the time of its
>>>>>> release). So the only thing we can do is release 5.5.1, 5.5.2,… where new
>>>>>> index/codecs are not allowed. And for that we already have a branch! Go
>>>>>> ahead and commit bugfixes there!
>>>>>>
>>>>> That makes no sense. There are only a handful of people committing
>>>>> index format changes. It's beyond simple for those people to understand
>>>>> once the next major version is released, don't put any more index format
>>>>> changes into the previous line.
>>>>>
>>>>> That is a very weak technical argument. Committers already have to
>>>>> remember how to deal with back compat and what changes can happen when.
>>>>> This is no different.
>>>>>
>>>>> - Mark
>>>>> --
>>>>> - Mark
>>>>> about.me/markrmiller
>>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>>
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>> --
> - Mark
> about.me/markrmiller
>

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
It's just an example though. Beyond simple features and improvements, there
are also lots of things we do under Other and Optimizations that we would
not not necessarily consider for a bug fix release (higher bar), but that
would be in a 5.6 release. A jetty point release update for example.

- Mark

On Tue, Feb 23, 2016 at 1:10 PM Nicholas Knize <nk...@gmail.com> wrote:

> > Things that help users migrate from 5x to 6x that we perhaps missed out.
>
> This may be semantics but these sound to me like bugs? Not features?
>
>
> On Tuesday, February 23, 2016, Anshum Gupta <an...@anshumgupta.net>
> wrote:
>
>> My thoughts exactly.
>>
>> The features that go into a possible 5.6 or 5.7 release would be stuff
>> that is unrelated to index format. Things that help users migrate from 5x
>> to 6x that we perhaps missed out. I'm just saying there's a real valid
>> possibility of such a release.
>>
>>
>> On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller <ma...@gmail.com>
>> wrote:
>>
>>> I just want to point out: just like the previous line of bug fix
>>> releases dies down heavily, so would the feature backports. They will
>>> likely be simple useful things rather than crazy complicated hard things.
>>> There probably won't be that many, just like the bug fix releases. Let's
>>> not pretend it's going to end up like an active branch with devs always
>>> wondering if the new codec they are slamming in is going to mess things up.
>>>
>>> If there is any demand for this, it's going to be by people on 5x for
>>> stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
>>> or may not be any better. Upgrading a major release can be quite disturbing
>>> and many users take a long, long time to do it.
>>>
>>> A 5.6, 5.7 would only be more stable. Fewer and simpler backports than
>>> our two main branches. Users can simply gobble them up, rather than choke
>>> them down like a major release. Useful features can be found that may not
>>> affect index format.
>>>
>>> Anyway, if there ends up being demand, I'll certainly be one of the
>>> 3 +1's needed.
>>>
>>> - Mark
>>>
>>> On Tue, Feb 23, 2016 at 12:18 PM Mark Miller <ma...@gmail.com>
>>> wrote:
>>>
>>>> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> To me it is quite clear that once we released 6.0, there is
>>>>> technically no possibility to release a brand new 5.6 Feature-Release! The
>>>>> main reason: 6.0 (if released before 5.6) will not be able to read indexes
>>>>> of 5.6 (because it does not know about the format at the time of its
>>>>> release). So the only thing we can do is release 5.5.1, 5.5.2,… where new
>>>>> index/codecs are not allowed. And for that we already have a branch! Go
>>>>> ahead and commit bugfixes there!
>>>>>
>>>> That makes no sense. There are only a handful of people committing
>>>> index format changes. It's beyond simple for those people to understand
>>>> once the next major version is released, don't put any more index format
>>>> changes into the previous line.
>>>>
>>>> That is a very weak technical argument. Committers already have to
>>>> remember how to deal with back compat and what changes can happen when.
>>>> This is no different.
>>>>
>>>> - Mark
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
> --
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

Posted by Nicholas Knize <nk...@gmail.com>.
> Things that help users migrate from 5x to 6x that we perhaps missed out.

This may be semantics but these sound to me like bugs? Not features?


On Tuesday, February 23, 2016, Anshum Gupta <an...@anshumgupta.net> wrote:

> My thoughts exactly.
>
> The features that go into a possible 5.6 or 5.7 release would be stuff
> that is unrelated to index format. Things that help users migrate from 5x
> to 6x that we perhaps missed out. I'm just saying there's a real valid
> possibility of such a release.
>
>
> On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller <markrmiller@gmail.com
> <javascript:_e(%7B%7D,'cvml','markrmiller@gmail.com');>> wrote:
>
>> I just want to point out: just like the previous line of bug fix releases
>> dies down heavily, so would the feature backports. They will likely be
>> simple useful things rather than crazy complicated hard things. There
>> probably won't be that many, just like the bug fix releases. Let's not
>> pretend it's going to end up like an active branch with devs always
>> wondering if the new codec they are slamming in is going to mess things up.
>>
>> If there is any demand for this, it's going to be by people on 5x for
>> stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
>> or may not be any better. Upgrading a major release can be quite disturbing
>> and many users take a long, long time to do it.
>>
>> A 5.6, 5.7 would only be more stable. Fewer and simpler backports than
>> our two main branches. Users can simply gobble them up, rather than choke
>> them down like a major release. Useful features can be found that may not
>> affect index format.
>>
>> Anyway, if there ends up being demand, I'll certainly be one of the
>> 3 +1's needed.
>>
>> - Mark
>>
>> On Tue, Feb 23, 2016 at 12:18 PM Mark Miller <markrmiller@gmail.com
>> <javascript:_e(%7B%7D,'cvml','markrmiller@gmail.com');>> wrote:
>>
>>> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <uwe@thetaphi.de
>>> <javascript:_e(%7B%7D,'cvml','uwe@thetaphi.de');>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> To me it is quite clear that once we released 6.0, there is technically
>>>> no possibility to release a brand new 5.6 Feature-Release! The main reason:
>>>> 6.0 (if released before 5.6) will not be able to read indexes of 5.6
>>>> (because it does not know about the format at the time of its release). So
>>>> the only thing we can do is release 5.5.1, 5.5.2,… where new index/codecs
>>>> are not allowed. And for that we already have a branch! Go ahead and commit
>>>> bugfixes there!
>>>>
>>> That makes no sense. There are only a handful of people committing index
>>> format changes. It's beyond simple for those people to understand once the
>>> next major version is released, don't put any more index format changes
>>> into the previous line.
>>>
>>> That is a very weak technical argument. Committers already have to
>>> remember how to deal with back compat and what changes can happen when.
>>> This is no different.
>>>
>>> - Mark
>>> --
>>> - Mark
>>> about.me/markrmiller
>>>
>> --
>> - Mark
>> about.me/markrmiller
>>
>
>
>
> --
> Anshum Gupta
>

Re: Removing branch_5x shortly

Posted by Anshum Gupta <an...@anshumgupta.net>.
My thoughts exactly.

The features that go into a possible 5.6 or 5.7 release would be stuff that
is unrelated to index format. Things that help users migrate from 5x to 6x
that we perhaps missed out. I'm just saying there's a real valid
possibility of such a release.


On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller <ma...@gmail.com> wrote:

> I just want to point out: just like the previous line of bug fix releases
> dies down heavily, so would the feature backports. They will likely be
> simple useful things rather than crazy complicated hard things. There
> probably won't be that many, just like the bug fix releases. Let's not
> pretend it's going to end up like an active branch with devs always
> wondering if the new codec they are slamming in is going to mess things up.
>
> If there is any demand for this, it's going to be by people on 5x for
> stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
> or may not be any better. Upgrading a major release can be quite disturbing
> and many users take a long, long time to do it.
>
> A 5.6, 5.7 would only be more stable. Fewer and simpler backports than our
> two main branches. Users can simply gobble them up, rather than choke them
> down like a major release. Useful features can be found that may not affect
> index format.
>
> Anyway, if there ends up being demand, I'll certainly be one of the 3 +1's
> needed.
>
> - Mark
>
> On Tue, Feb 23, 2016 at 12:18 PM Mark Miller <ma...@gmail.com>
> wrote:
>
>> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> To me it is quite clear that once we released 6.0, there is technically
>>> no possibility to release a brand new 5.6 Feature-Release! The main reason:
>>> 6.0 (if released before 5.6) will not be able to read indexes of 5.6
>>> (because it does not know about the format at the time of its release). So
>>> the only thing we can do is release 5.5.1, 5.5.2,… where new index/codecs
>>> are not allowed. And for that we already have a branch! Go ahead and commit
>>> bugfixes there!
>>>
>> That makes no sense. There are only a handful of people committing index
>> format changes. It's beyond simple for those people to understand once the
>> next major version is released, don't put any more index format changes
>> into the previous line.
>>
>> That is a very weak technical argument. Committers already have to
>> remember how to deal with back compat and what changes can happen when.
>> This is no different.
>>
>> - Mark
>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> - Mark
> about.me/markrmiller
>



-- 
Anshum Gupta

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
I just want to point out: just like the previous line of bug fix releases
dies down heavily, so would the feature backports. They will likely be
simple useful things rather than crazy complicated hard things. There
probably won't be that many, just like the bug fix releases. Let's not
pretend it's going to end up like an active branch with devs always
wondering if the new codec they are slamming in is going to mess things up.

If there is any demand for this, it's going to be by people on 5x for
stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
or may not be any better. Upgrading a major release can be quite disturbing
and many users take a long, long time to do it.

A 5.6, 5.7 would only be more stable. Fewer and simpler backports than our
two main branches. Users can simply gobble them up, rather than choke them
down like a major release. Useful features can be found that may not affect
index format.

Anyway, if there ends up being demand, I'll certainly be one of the 3 +1's
needed.

- Mark

On Tue, Feb 23, 2016 at 12:18 PM Mark Miller <ma...@gmail.com> wrote:

> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>
>> Hi,
>>
>>
>>
>> To me it is quite clear that once we released 6.0, there is technically
>> no possibility to release a brand new 5.6 Feature-Release! The main reason:
>> 6.0 (if released before 5.6) will not be able to read indexes of 5.6
>> (because it does not know about the format at the time of its release). So
>> the only thing we can do is release 5.5.1, 5.5.2,… where new index/codecs
>> are not allowed. And for that we already have a branch! Go ahead and commit
>> bugfixes there!
>>
> That makes no sense. There are only a handful of people committing index
> format changes. It's beyond simple for those people to understand once the
> next major version is released, don't put any more index format changes
> into the previous line.
>
> That is a very weak technical argument. Committers already have to
> remember how to deal with back compat and what changes can happen when.
> This is no different.
>
> - Mark
> --
> - Mark
> about.me/markrmiller
>
-- 
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler <uw...@thetaphi.de> wrote:

> Hi,
>
>
>
> To me it is quite clear that once we released 6.0, there is technically no
> possibility to release a brand new 5.6 Feature-Release! The main reason:
> 6.0 (if released before 5.6) will not be able to read indexes of 5.6
> (because it does not know about the format at the time of its release). So
> the only thing we can do is release 5.5.1, 5.5.2,… where new index/codecs
> are not allowed. And for that we already have a branch! Go ahead and commit
> bugfixes there!
>
That makes no sense. There are only a handful of people committing index
format changes. It's beyond simple for those people to understand once the
next major version is released, don't put any more index format changes
into the previous line.

That is a very weak technical argument. Committers already have to remember
how to deal with back compat and what changes can happen when. This is no
different.

- Mark
-- 
- Mark
about.me/markrmiller

RE: Removing branch_5x shortly

Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,

 

To me it is quite clear that once we released 6.0, there is technically no possibility to release a brand new 5.6 Feature-Release! The main reason: 6.0 (if released before 5.6) will not be able to read indexes of 5.6 (because it does not know about the format at the time of its release). So the only thing we can do is release 5.5.1, 5.5.2,… where new index/codecs are not allowed. And for that we already have a branch! Go ahead and commit bugfixes there!

 

This may not fully apply to Solr on its own, but for the Lucene part this is a hard restriction (because we write version numbers into the index and compare them – so 5.6 would then break 6.0 and may lead to fatal index corrumption).

 

So let us simply focus on getting 6.0 out – currently there was nothing significant backported to 5.x branch that would rectify a release. And bugfixes can still go into 5.5 branch, we may also commit a performance optimization into 5.5, unless it changes index formats.

 

Personally, I will -1 every release that happens after 5.5 that changes index formats. This is just too risky!

 

BTW. Following Mike’s release notes I posted the same thing on German Jaxenter Newsletter: https://jaxenter.de/apache-lucene-und-solr-5-5-veroeffentlicht-35271 (the smaller title over the main title reads “Last feature release before version 6”).  I assume it will be translated and be released on English Jaxenter, too.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: uwe@thetaphi.de

 

From: Anshum Gupta [mailto:anshum@anshumgupta.net] 
Sent: Tuesday, February 23, 2016 5:53 PM
To: dev@lucene.apache.org
Subject: Re: Removing branch_5x shortly

 

Sure, as I said, I agree I should have read and edited the notes. But in any case, I just thought I had missed something here. I completely understand that the job of the release manager is lonely but it was better that I got clarity on this rather than assuming things. 

 

I really appreciate you taking time and effort to manage the releases.

 

On Tue, Feb 23, 2016 at 8:37 AM, Michael McCandless <lucene@mikemccandless.com <ma...@mikemccandless.com> > wrote:

Anshum, if you don't like the wording of the release notes, please
please please go and read them on the wiki and edit ahead of time,
before the release is announced.

It's a lonely job for the RM (alone) to go and word this, especially
when they (me) are not familiar with all of the changes.  In the
future when the RM says "I created the Release Notes placeholders on
the wiki, please edit them", which I did ~ 2 weeks ago, please do!

Second, consensus here was to not remove the git branch since 1) this
is apparently technically a disaster with git, requiring all users who
had cloned to run a cryptic command, and 2) it would "preclude" a
future 5.6.0 (though, that's not really true).  It seems to me we
should never remove any pushed git branches.

Third, there is no reason/need to talk about consensus about a
hypothetical future 5.6.0 release: that depends entirely on how the
future unfolds, as Jack and Yonik explain.  In general, in your life,
there is no need (and indeed only added risk) to make a decision today
that can safely be postponed.  Let the future unfold first so you have
all data, and only make the (better informed) decision once you must.

Fourth, by releasing 6.0, shortly, we (Lucene/Solr devs) are declaring
to our users that we intend future new features to go into 6.1, 6.2,
etc., the new stable branch.  I don't think we want / can afford to
have two stable branches at once.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Feb 23, 2016 at 10:55 AM, Jack Krupansky
<jack.krupansky@gmail.com <ma...@gmail.com> > wrote:
> Sure, it will all hinge on the uptake of 6.x vs. demand for features in 5.x
> from sites who feel that they cannot easily upgrade to 6.x. But in any case,
> it seems reasonable for there to be a distinct bias in favor of people
> migrating to 6.x for new features rather than divert attention from 6.x, and
> that new features should be optimized for 6.x rather than dumbed-down to
> remain compatible with 5.x.
>
> Sure, practicality may well force a 5.6, but as you say, we haven't gotten
> to that bridge yet. I mean, is anybody proposing a list of urgent features
> that should go in 5.x rather than 6.x?
>
> It does seem clear that the technical possibility of a 5.6 remains even
> though the clear bias and expectation is that 6.x is where people should be
> looking for new features.
>
> Personally, I don't think we will have a clear answer until we get to 6.1 -
> at that point it will be reasonably clear whether demand for enhancement of
> 5.x is really there or not.
>
> I say all of this presuming that 6.0 is imminent within the next few weeks.
> It seems reasonable to have feature releases (minor releases) on a monthly
> basis, so if 6.0 is not out a month from now, then a 5.6 would be a very
> reasonable expectation.
>
>
> -- Jack Krupansky
>
> On Tue, Feb 23, 2016 at 10:34 AM, Anshum Gupta <anshum@anshumgupta.net <ma...@anshumgupta.net> >
> wrote:
>>
>> I thought we had a consensus here in terms of being able to have another
>> 5x release if someone felt the need and volunteered but I guess that wasn't
>> the case. I say that because I just saw the following line in the release
>> notes for 5.5:
>>
>> "This is expected to be the last 5.x feature release before Solr 6.0.0."
>>
>> If everyone else also thinks that it would have not been reasonable to
>> leave a possibility of another 5x release, I'm fine. We might have to
>> evaluate it if we get to that bridge though.
>>
>>
>> On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <noble.paul@gmail.com <ma...@gmail.com> > wrote:
>>>
>>> Yeah, please don't remove it. Let it be there.
>>>
>>> On Feb 21, 2016 01:02, "Uwe Schindler" <uwe@thetaphi.de <ma...@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 <ma...@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 <ma...@lucene.apache.org> 
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 
>>>>>
>>>>
>>>> --
>>>> Uwe Schindler
>>>> H.-H.-Meier-Allee 63, 28213 Bremen
>>>> http://www.thetaphi.de
>>
>>
>>
>>
>> --
>> Anshum Gupta
>
>

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 





 

-- 

Anshum Gupta

Re: Removing branch_5x shortly

Posted by Anshum Gupta <an...@anshumgupta.net>.
Sure, as I said, I agree I should have read and edited the notes. But in
any case, I just thought I had missed something here. I completely
understand that the job of the release manager is lonely but it was better
that I got clarity on this rather than assuming things.

I really appreciate you taking time and effort to manage the releases.

On Tue, Feb 23, 2016 at 8:37 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:

> Anshum, if you don't like the wording of the release notes, please
> please please go and read them on the wiki and edit ahead of time,
> before the release is announced.
>
> It's a lonely job for the RM (alone) to go and word this, especially
> when they (me) are not familiar with all of the changes.  In the
> future when the RM says "I created the Release Notes placeholders on
> the wiki, please edit them", which I did ~ 2 weeks ago, please do!
>
> Second, consensus here was to not remove the git branch since 1) this
> is apparently technically a disaster with git, requiring all users who
> had cloned to run a cryptic command, and 2) it would "preclude" a
> future 5.6.0 (though, that's not really true).  It seems to me we
> should never remove any pushed git branches.
>
> Third, there is no reason/need to talk about consensus about a
> hypothetical future 5.6.0 release: that depends entirely on how the
> future unfolds, as Jack and Yonik explain.  In general, in your life,
> there is no need (and indeed only added risk) to make a decision today
> that can safely be postponed.  Let the future unfold first so you have
> all data, and only make the (better informed) decision once you must.
>
> Fourth, by releasing 6.0, shortly, we (Lucene/Solr devs) are declaring
> to our users that we intend future new features to go into 6.1, 6.2,
> etc., the new stable branch.  I don't think we want / can afford to
> have two stable branches at once.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Feb 23, 2016 at 10:55 AM, Jack Krupansky
> <ja...@gmail.com> wrote:
> > Sure, it will all hinge on the uptake of 6.x vs. demand for features in
> 5.x
> > from sites who feel that they cannot easily upgrade to 6.x. But in any
> case,
> > it seems reasonable for there to be a distinct bias in favor of people
> > migrating to 6.x for new features rather than divert attention from 6.x,
> and
> > that new features should be optimized for 6.x rather than dumbed-down to
> > remain compatible with 5.x.
> >
> > Sure, practicality may well force a 5.6, but as you say, we haven't
> gotten
> > to that bridge yet. I mean, is anybody proposing a list of urgent
> features
> > that should go in 5.x rather than 6.x?
> >
> > It does seem clear that the technical possibility of a 5.6 remains even
> > though the clear bias and expectation is that 6.x is where people should
> be
> > looking for new features.
> >
> > Personally, I don't think we will have a clear answer until we get to
> 6.1 -
> > at that point it will be reasonably clear whether demand for enhancement
> of
> > 5.x is really there or not.
> >
> > I say all of this presuming that 6.0 is imminent within the next few
> weeks.
> > It seems reasonable to have feature releases (minor releases) on a
> monthly
> > basis, so if 6.0 is not out a month from now, then a 5.6 would be a very
> > reasonable expectation.
> >
> >
> > -- Jack Krupansky
> >
> > On Tue, Feb 23, 2016 at 10:34 AM, Anshum Gupta <an...@anshumgupta.net>
> > wrote:
> >>
> >> I thought we had a consensus here in terms of being able to have another
> >> 5x release if someone felt the need and volunteered but I guess that
> wasn't
> >> the case. I say that because I just saw the following line in the
> release
> >> notes for 5.5:
> >>
> >> "This is expected to be the last 5.x feature release before Solr 6.0.0."
> >>
> >> If everyone else also thinks that it would have not been reasonable to
> >> leave a possibility of another 5x release, I'm fine. We might have to
> >> evaluate it if we get to that bridge though.
> >>
> >>
> >> On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <no...@gmail.com>
> wrote:
> >>>
> >>> Yeah, please don't remove it. Let it be there.
> >>>
> >>> On Feb 21, 2016 01:02, "Uwe Schindler" <uw...@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
> >>>> <da...@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
> >>
> >>
> >>
> >>
> >> --
> >> Anshum Gupta
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>


-- 
Anshum Gupta

Re: Removing branch_5x shortly

Posted by Michael McCandless <lu...@mikemccandless.com>.
Anshum, if you don't like the wording of the release notes, please
please please go and read them on the wiki and edit ahead of time,
before the release is announced.

It's a lonely job for the RM (alone) to go and word this, especially
when they (me) are not familiar with all of the changes.  In the
future when the RM says "I created the Release Notes placeholders on
the wiki, please edit them", which I did ~ 2 weeks ago, please do!

Second, consensus here was to not remove the git branch since 1) this
is apparently technically a disaster with git, requiring all users who
had cloned to run a cryptic command, and 2) it would "preclude" a
future 5.6.0 (though, that's not really true).  It seems to me we
should never remove any pushed git branches.

Third, there is no reason/need to talk about consensus about a
hypothetical future 5.6.0 release: that depends entirely on how the
future unfolds, as Jack and Yonik explain.  In general, in your life,
there is no need (and indeed only added risk) to make a decision today
that can safely be postponed.  Let the future unfold first so you have
all data, and only make the (better informed) decision once you must.

Fourth, by releasing 6.0, shortly, we (Lucene/Solr devs) are declaring
to our users that we intend future new features to go into 6.1, 6.2,
etc., the new stable branch.  I don't think we want / can afford to
have two stable branches at once.

Mike McCandless

http://blog.mikemccandless.com

On Tue, Feb 23, 2016 at 10:55 AM, Jack Krupansky
<ja...@gmail.com> wrote:
> Sure, it will all hinge on the uptake of 6.x vs. demand for features in 5.x
> from sites who feel that they cannot easily upgrade to 6.x. But in any case,
> it seems reasonable for there to be a distinct bias in favor of people
> migrating to 6.x for new features rather than divert attention from 6.x, and
> that new features should be optimized for 6.x rather than dumbed-down to
> remain compatible with 5.x.
>
> Sure, practicality may well force a 5.6, but as you say, we haven't gotten
> to that bridge yet. I mean, is anybody proposing a list of urgent features
> that should go in 5.x rather than 6.x?
>
> It does seem clear that the technical possibility of a 5.6 remains even
> though the clear bias and expectation is that 6.x is where people should be
> looking for new features.
>
> Personally, I don't think we will have a clear answer until we get to 6.1 -
> at that point it will be reasonably clear whether demand for enhancement of
> 5.x is really there or not.
>
> I say all of this presuming that 6.0 is imminent within the next few weeks.
> It seems reasonable to have feature releases (minor releases) on a monthly
> basis, so if 6.0 is not out a month from now, then a 5.6 would be a very
> reasonable expectation.
>
>
> -- Jack Krupansky
>
> On Tue, Feb 23, 2016 at 10:34 AM, Anshum Gupta <an...@anshumgupta.net>
> wrote:
>>
>> I thought we had a consensus here in terms of being able to have another
>> 5x release if someone felt the need and volunteered but I guess that wasn't
>> the case. I say that because I just saw the following line in the release
>> notes for 5.5:
>>
>> "This is expected to be the last 5.x feature release before Solr 6.0.0."
>>
>> If everyone else also thinks that it would have not been reasonable to
>> leave a possibility of another 5x release, I'm fine. We might have to
>> evaluate it if we get to that bridge though.
>>
>>
>> On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <no...@gmail.com> wrote:
>>>
>>> Yeah, please don't remove it. Let it be there.
>>>
>>> On Feb 21, 2016 01:02, "Uwe Schindler" <uw...@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
>>>> <da...@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
>>
>>
>>
>>
>> --
>> Anshum Gupta
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Yonik Seeley <ys...@gmail.com>.
Just like bugfix releases or any other releases, additional 5.x
releases may be driven by those who need/desire them.
A release requires someone to to the work, and at least 3 +1 PMC votes
(and more +1s than -1s).

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Jack Krupansky <ja...@gmail.com>.
Sure, it will all hinge on the uptake of 6.x vs. demand for features in 5.x
from sites who feel that they cannot easily upgrade to 6.x. But in any
case, it seems reasonable for there to be a distinct bias in favor of
people migrating to 6.x for new features rather than divert attention from
6.x, and that new features should be optimized for 6.x rather than
dumbed-down to remain compatible with 5.x.

Sure, practicality may well force a 5.6, but as you say, we haven't gotten
to that bridge yet. I mean, is anybody proposing a list of urgent features
that should go in 5.x rather than 6.x?

It does seem clear that the technical possibility of a 5.6 remains even
though the clear bias and expectation is that 6.x is where people should be
looking for new features.

Personally, I don't think we will have a clear answer until we get to 6.1 -
at that point it will be reasonably clear whether demand for enhancement of
5.x is really there or not.

I say all of this presuming that 6.0 is imminent within the next few weeks.
It seems reasonable to have feature releases (minor releases) on a monthly
basis, so if 6.0 is not out a month from now, then a 5.6 would be a very
reasonable expectation.


-- Jack Krupansky

On Tue, Feb 23, 2016 at 10:34 AM, Anshum Gupta <an...@anshumgupta.net>
wrote:

> I thought we had a consensus here in terms of being able to have another
> 5x release if someone felt the need and volunteered but I guess that wasn't
> the case. I say that because I just saw the following line in the release
> notes for 5.5:
>
> "This is expected to be the last 5.x feature release before Solr 6.0.0."
>
> If everyone else also thinks that it would have not been reasonable to
> leave a possibility of another 5x release, I'm fine. We might have to
> evaluate it *if* we get to that bridge though.
>
>
> On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <no...@gmail.com> wrote:
>
>> Yeah, please don't remove it. Let it be there.
>> On Feb 21, 2016 01:02, "Uwe Schindler" <uw...@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
>>>
>>
>
>
> --
> Anshum Gupta
>

Re: Removing branch_5x shortly

Posted by Shai Erera <se...@gmail.com>.
We might want to have a 'deprecation' release, not sure what's our policy
about that. I.e. is it OK to release 6.0, then deprecate some APIs that we
"forgot to deprecate in 5.x" and remove them in 6.1?

I say let's keep branch_5x for a little while. Removing is always possible.

Shai

On Tue, Feb 23, 2016 at 5:34 PM Anshum Gupta <an...@anshumgupta.net> wrote:

> I thought we had a consensus here in terms of being able to have another
> 5x release if someone felt the need and volunteered but I guess that wasn't
> the case. I say that because I just saw the following line in the release
> notes for 5.5:
>
> "This is expected to be the last 5.x feature release before Solr 6.0.0."
>
> If everyone else also thinks that it would have not been reasonable to
> leave a possibility of another 5x release, I'm fine. We might have to
> evaluate it *if* we get to that bridge though.
>
>
> On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <no...@gmail.com> wrote:
>
>> Yeah, please don't remove it. Let it be there.
>> On Feb 21, 2016 01:02, "Uwe Schindler" <uw...@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
>>>
>>
>
>
> --
> Anshum Gupta
>

Re: Removing branch_5x shortly

Posted by Anshum Gupta <an...@anshumgupta.net>.
I thought we had a consensus here in terms of being able to have another 5x
release if someone felt the need and volunteered but I guess that wasn't
the case. I say that because I just saw the following line in the release
notes for 5.5:

"This is expected to be the last 5.x feature release before Solr 6.0.0."

If everyone else also thinks that it would have not been reasonable to
leave a possibility of another 5x release, I'm fine. We might have to
evaluate it *if* we get to that bridge though.


On Sat, Feb 20, 2016 at 3:10 PM, Noble Paul <no...@gmail.com> wrote:

> Yeah, please don't remove it. Let it be there.
> On Feb 21, 2016 01:02, "Uwe Schindler" <uw...@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
>>
>


-- 
Anshum Gupta

Re: Removing branch_5x shortly

Posted by Noble Paul <no...@gmail.com>.
Yeah, please don't remove it. Let it be there.
On Feb 21, 2016 01:02, "Uwe Schindler" <uw...@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
>

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
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 <ja...@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 <uw...@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

Re: Removing branch_5x shortly

Posted by Jack Krupansky <ja...@gmail.com>.
+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 <uw...@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
>

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
Not the norm is an understatement reading that issue :)

- Mark

On Sat, Feb 20, 2016 at 4:04 PM Anshum Gupta <an...@anshumgupta.net> wrote:

> Here's a similar question that came up during the 5.0 release.
>
> https://issues.apache.org/jira/browse/LUCENE-5944?focusedCommentId=14138919&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14138919
>
> The reply to this was convincing back then as 5.0 was released for
> different reasons, and in different circumstances. It certainly wasn't the
> norm.
>
> Unless I'm missing something here, I don't see a reason to not keep 5x and
> even potentially release 5.6 at some point as long as some one has a reason
> and the time to work on a 5.6 release.
>
> Also, as Uwe said, it might be wasted effort committing to the 5x branch
> but that wouldn't hurt us.
>
>
> On Sat, Feb 20, 2016 at 12:41 PM, Yonik Seeley <ys...@gmail.com> wrote:
>
>> On Sat, Feb 20, 2016 at 3:33 PM, Michael McCandless
>> <lu...@mikemccandless.com> wrote:
>> > I was simply going by what we did when we released 5.0, which was to
>> > remove the 4.x branch (or rename it to 4.10.x maybe, but the net
>> > effect is the same).  I thought this was the practice for a major
>> > release.
>>
>> That was a one-off that caught a lot of people by surprise.  It had
>> not been done on previous major releases.
>> There was already even a lot of work toward 4.11 when the deletion
>> happened IIRC.
>>
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>
-- 
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

Posted by Anshum Gupta <an...@anshumgupta.net>.
Here's a similar question that came up during the 5.0 release.
https://issues.apache.org/jira/browse/LUCENE-5944?focusedCommentId=14138919&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14138919

The reply to this was convincing back then as 5.0 was released for
different reasons, and in different circumstances. It certainly wasn't the
norm.

Unless I'm missing something here, I don't see a reason to not keep 5x and
even potentially release 5.6 at some point as long as some one has a reason
and the time to work on a 5.6 release.

Also, as Uwe said, it might be wasted effort committing to the 5x branch
but that wouldn't hurt us.


On Sat, Feb 20, 2016 at 12:41 PM, Yonik Seeley <ys...@gmail.com> wrote:

> On Sat, Feb 20, 2016 at 3:33 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
> > I was simply going by what we did when we released 5.0, which was to
> > remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> > effect is the same).  I thought this was the practice for a major
> > release.
>
> That was a one-off that caught a lot of people by surprise.  It had
> not been done on previous major releases.
> There was already even a lot of work toward 4.11 when the deletion
> happened IIRC.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>


-- 
Anshum Gupta

Re: Removing branch_5x shortly

Posted by Yonik Seeley <ys...@gmail.com>.
On Sat, Feb 20, 2016 at 3:33 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> I was simply going by what we did when we released 5.0, which was to
> remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> effect is the same).  I thought this was the practice for a major
> release.

That was a one-off that caught a lot of people by surprise.  It had
not been done on previous major releases.
There was already even a lot of work toward 4.11 when the deletion
happened IIRC.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Dawid Weiss <da...@gmail.com>.
> It sounds like one must assume git's gc is immediate, i.e. upon removing the branch, any commits not reachable by any other "roots" would be deleted, even if you "remembered" their specific commit hashes yourself.

No, it isn't immediate. git tries hard to preserve your work in case
you screw up. If you do want to "System.gc()" you need to do this as a
two-step process in git -- expunge the reflog and then rewrite
commits. It is *very* unusual that you'd really want to do it (much
like trying to "brute-force" a GC in Java).

Dawid


On Sat, Feb 20, 2016 at 9:33 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> I was simply going by what we did when we released 5.0, which was to
> remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> effect is the same).  I thought this was the practice for a major
> release.
>
> But it sounds like removing this branch in git is ... not a good idea
> technically.
>
> And even if it were technically possible (having everyone run "git
> remote prune origin"), clearly everyone here disagrees we should do
> so.
>
> So I'll leave it be.
>
> Thanks for the git explanation Dawid!  It sounds like one must assume
> git's gc is immediate, i.e. upon removing the branch, any commits not
> reachable by any other "roots" would be deleted, even if you
> "remembered" their specific commit hashes yourself.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <uw...@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
>> <da...@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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Michael McCandless <lu...@mikemccandless.com>.
I was simply going by what we did when we released 5.0, which was to
remove the 4.x branch (or rename it to 4.10.x maybe, but the net
effect is the same).  I thought this was the practice for a major
release.

But it sounds like removing this branch in git is ... not a good idea
technically.

And even if it were technically possible (having everyone run "git
remote prune origin"), clearly everyone here disagrees we should do
so.

So I'll leave it be.

Thanks for the git explanation Dawid!  It sounds like one must assume
git's gc is immediate, i.e. upon removing the branch, any commits not
reachable by any other "roots" would be deleted, even if you
"remembered" their specific commit hashes yourself.

Mike McCandless

http://blog.mikemccandless.com

On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <uw...@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
> <da...@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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <da...@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

Re: Removing branch_5x shortly

Posted by Dawid Weiss <da...@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

Re: Removing branch_5x shortly

Posted by Mark Miller <ma...@gmail.com>.
Can't we tag it and then delete the branch?

I'm not a fan of removal as a way to prevent commits though. We should see
if infra let's us put in any git hooks and protect branches from there.

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?

- Mark

On Sat, Feb 20, 2016 at 1:37 PM Dawid Weiss <da...@gmail.com> wrote:

> >   git push origin --delete branch_5x
> >
> > (Instead of the crazy all-powerful-colon syntax).
>
> Ok. I don't think it's the right way to do it.
>
> > This just removes the "pointer" (branch_5x) to the latest commit hash
> > right?  The commits unique to that branch still remain unless we ask
> > git to reclaim them?  Or does git reclaim un-referenced nodes on its
> > own sometimes...?
>
> This means you need to re-read my git tutorials :) Or perhaps I should
> add one specific to deleting a (remote) reference...
>
> In short: git gc is much like Java's gc. Think of git commits as Java
> objects -- if they are not referenced from any "gc roots" they are
> eligible for permanent deletion. Git's "gc roots" are essentially
> those commits which are pointed to by any reference (tag, branch...
> anything you see when you issue "git show-ref"). Git's equivalent of
> Java's "references" are "parent" commits from a commit (a single
> commit can have one parent -> linear history or multiple parents -> a
> merge). There is also a "temporary backlog" of recent operations
> called a "reflog" which points to all commits involved in recent local
> commands... but when this expires the commits will be eventually
> dropped.
>
> Anything not "reachable" from gc roots or the reflog is eligible for
> permanent deletion. So any commits not reachable from a tag or other
> branch would be forgotten after you delete branch_5x.
>
> There's also another aspect of deleting a remote branch -- this
> deletion isn't automatically "propagated" to any other forks (so other
> committers would still see a remote branch_5x). You'd have to ask
> everyone to prune remote references.
>
> For these reasons I think we should just leave branch_5x as is. If you
> really want to enforce no further commits on it I'd delete all the
> files from that branch and leave a README file saying this branch is
> effectively dead.
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

Posted by Dawid Weiss <da...@gmail.com>.
>   git push origin --delete branch_5x
>
> (Instead of the crazy all-powerful-colon syntax).

Ok. I don't think it's the right way to do it.

> This just removes the "pointer" (branch_5x) to the latest commit hash
> right?  The commits unique to that branch still remain unless we ask
> git to reclaim them?  Or does git reclaim un-referenced nodes on its
> own sometimes...?

This means you need to re-read my git tutorials :) Or perhaps I should
add one specific to deleting a (remote) reference...

In short: git gc is much like Java's gc. Think of git commits as Java
objects -- if they are not referenced from any "gc roots" they are
eligible for permanent deletion. Git's "gc roots" are essentially
those commits which are pointed to by any reference (tag, branch...
anything you see when you issue "git show-ref"). Git's equivalent of
Java's "references" are "parent" commits from a commit (a single
commit can have one parent -> linear history or multiple parents -> a
merge). There is also a "temporary backlog" of recent operations
called a "reflog" which points to all commits involved in recent local
commands... but when this expires the commits will be eventually
dropped.

Anything not "reachable" from gc roots or the reflog is eligible for
permanent deletion. So any commits not reachable from a tag or other
branch would be forgotten after you delete branch_5x.

There's also another aspect of deleting a remote branch -- this
deletion isn't automatically "propagated" to any other forks (so other
committers would still see a remote branch_5x). You'd have to ask
everyone to prune remote references.

For these reasons I think we should just leave branch_5x as is. If you
really want to enforce no further commits on it I'd delete all the
files from that branch and leave a README file saying this branch is
effectively dead.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Michael McCandless <lu...@mikemccandless.com>.
Thanks for asking :)

I was just going to do:

  git push origin --delete branch_5x

(Instead of the crazy all-powerful-colon syntax).

This just removes the "pointer" (branch_5x) to the latest commit hash
right?  The commits unique to that branch still remain unless we ask
git to reclaim them?  Or does git reclaim un-referenced nodes on its
own sometimes...?

Mike McCandless

http://blog.mikemccandless.com


On Sat, Feb 20, 2016 at 12:17 PM, Dawid Weiss <da...@gmail.com> wrote:
>
> Before you do push anything can you explain or give the commands you plan to
> execute Mike? Deleting a branch is typically not a good idea that's why I
> ask.
>
> On Feb 20, 2016 17:52, "Michael McCandless" <lu...@mikemccandless.com>
> wrote:
>>
>> Please don't back-port anything to branch_5x: I'd like to remove it,
>> i.e. any back-ports from master should be only bug fixes and go to
>> branch_5_5's next bug fix release (5.5.1) instead.
>>
>> I see some recent commits for Solr here ... if these are really
>> bug-fixes, please re-push to 5.5 branch instead.
>>
>> The current tip of branch_5x is
>> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
>> how git will GC this once I remove branch_5x.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Removing branch_5x shortly

Posted by Dawid Weiss <da...@gmail.com>.
Before you do push anything can you explain or give the commands you plan
to execute Mike? Deleting a branch is typically not a good idea that's why
I ask.
On Feb 20, 2016 17:52, "Michael McCandless" <lu...@mikemccandless.com>
wrote:

> Please don't back-port anything to branch_5x: I'd like to remove it,
> i.e. any back-ports from master should be only bug fixes and go to
> branch_5_5's next bug fix release (5.5.1) instead.
>
> I see some recent commits for Solr here ... if these are really
> bug-fixes, please re-push to 5.5 branch instead.
>
> The current tip of branch_5x is
> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
> how git will GC this once I remove branch_5x.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>