You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Chris Hostetter <ho...@fucit.org> on 2010/04/26 20:43:52 UTC
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
I didn't follow the Version API relaxation thread (my fault: i thought it
was focused solely on how we were dealing with o.a.l.Version and lots of
smart people were talking in ernest so i left it to them to make smart
choices) but looking at this proposal, I'm at a loss to understand how
it's any differnet then what we do today: we have a trunk, we add lots of
features, and we document when compatibility breaks (and as a result rev
our version numbers accordingly) ... in contrast, we have the "release
branches" where we backport changes that don't break compatibility. the
only distinction seems to be this sentence...
: The stable line of development (on a branch) will get
: non-back-compat-breaking changes, and will be released more often (as
: minor releases and possible also .Z bugfix releases).
...i don't know that anyone would say we release "more often" off of hte
existing release branches, but that seems more an issue of practice then
procedure.
So I feel like i must be missunderstanidng the goal here.
My best guess: that what this is really suggesting is that "trunk"
*always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
4.2, etc...) happen on "more stable" branches off of the major version
release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
If i'm wrong, then can someone please explain it to me in a concreate
actionable way? (ie: specific examples of actions people would take
moving forward under this new procedure)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by DM Smith <dm...@gmail.com>.
On 04/26/2010 02:43 PM, Chris Hostetter wrote:
> I didn't follow the Version API relaxation thread (my fault: i thought it
> was focused solely on how we were dealing with o.a.l.Version and lots of
> smart people were talking in ernest so i left it to them to make smart
> choices) but looking at this proposal, I'm at a loss to understand how
> it's any differnet then what we do today: we have a trunk, we add lots of
> features, and we document when compatibility breaks (and as a result rev
> our version numbers accordingly) ... in contrast, we have the "release
> branches" where we backport changes that don't break compatibility. the
> only distinction seems to be this sentence...
>
> : The stable line of development (on a branch) will get
> : non-back-compat-breaking changes, and will be released more often (as
> : minor releases and possible also .Z bugfix releases).
>
> ...i don't know that anyone would say we release "more often" off of hte
> existing release branches, but that seems more an issue of practice then
> procedure.
>
> So I feel like i must be missunderstanidng the goal here.
>
> My best guess: that what this is really suggesting is that "trunk"
> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
> 4.2, etc...) happen on "more stable" branches off of the major version
> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>
> If i'm wrong, then can someone please explain it to me in a concreate
> actionable way? (ie: specific examples of actions people would take
> moving forward under this new procedure)
>
As I understand it:
Your guess is correct.
The goal is to have future development not be encumbered by bw compat
maintenance.
Trunk will not try to maintain backward compatibility. (As I see it
there is no longer any point to Version in trunk.)
It probably won't have deprecations.
There will be no 3.9 release that differs from 4.0 only in deprecations
removed.
Moving from 3.x to 4.0 will require users to be deliberate and careful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Earwin Burrfoot <ea...@gmail.com>.
I'd like to +1 on this with all my tiny non-committer might.
On Mon, Apr 26, 2010 at 23:06, Michael McCandless
<lu...@mikemccandless.com> wrote:
> This is exactly the intention behind the proposal we are voting on.
>
> Big changes, that'd be destabilizing if attempted on the stable
> branch, would be done only on unstable (= trunk).
>
> More "normal" changes, which can still include deprecations/some back
> compat, would be done on the stable branch and unstable.
>
> So, eg, rather than attempt back compat for a big change like flex, we
> would instead do it only in unstable and it'd first become "available"
> in the next .0 release.
>
> By segregating the big changes away from stable we should be able to
> keep stronger back compat on stable. We also save our resources not
> building costly back compat layers that, because of their complexity,
> bring their own problems. Also, our release numbers are more
> "standard" -- the .0 release will have major changes (unlike today
> where is has no changes except removal of deprecations).
>
> Mike
>
> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>> My best guess: that what this is really suggesting is that "trunk"
>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>
>> This is what I would like. Not sure if that's what will come from the
>> current proposal or not, but seems so to me.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.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
>
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for
unstable Solr/Lucene development
Posted by Michael McCandless <lu...@mikemccandless.com>.
Right, and we'd remove the 2 non-sophisticated :) back compat layers
in flex, and I'd make an index migration tool for 4.0.
Mike
On Mon, Apr 26, 2010 at 11:12 PM, Shai Erera <se...@gmail.com> wrote:
> I would like to think that if 3.1 is cut w/o flex (and following dependent
> issues), then we will allow people to re-commit the already committed code
> changes to the 3.1 branch before it is released. Then, flex et al. become
> the next 4.0 and 3.1 will be the first minor stable release of 3.x w/ some
> of the features that came post-flex (exercising our svn merge skills :)).
>
> Shai
>
> On Mon, Apr 26, 2010 at 11:01 PM, DM Smith <dm...@gmail.com> wrote:
>>
>> Assuming that the vote passed: I'm wondering where this leaves us for the
>> near term? How it works in practice.
>>
>> There have been a lot of recent changes and flex has landed. There are a
>> bunch of issues marked as 3.1 and many (most?) have decent patches.
>>
>> Let's suppose a 3.1 release soon. What would it be/contain and how would
>> it work?
>>
>> -- DM
>>
>> On 04/26/2010 03:55 PM, Shai Erera wrote:
>>>
>>> An interesting point was made on Version - we cannot remove it from
>>> trunk just to reintroduce it when trunk is released as .0 and then
>>> followed by .1 .2 "stable" releases … otherwise it would
>>> appear/disappear constantly :)?
>>>
>>> So I guess Versuon should go away entirely?
>>>
>>> Shai
>>>
>>> On Monday, April 26, 2010, Michael McCandless<lu...@mikemccandless.com>
>>> wrote:
>>>
>>>>
>>>> This is exactly the intention behind the proposal we are voting on.
>>>>
>>>> Big changes, that'd be destabilizing if attempted on the stable
>>>> branch, would be done only on unstable (= trunk).
>>>>
>>>> More "normal" changes, which can still include deprecations/some back
>>>> compat, would be done on the stable branch and unstable.
>>>>
>>>> So, eg, rather than attempt back compat for a big change like flex, we
>>>> would instead do it only in unstable and it'd first become "available"
>>>> in the next .0 release.
>>>>
>>>> By segregating the big changes away from stable we should be able to
>>>> keep stronger back compat on stable. We also save our resources not
>>>> building costly back compat layers that, because of their complexity,
>>>> bring their own problems. Also, our release numbers are more
>>>> "standard" -- the .0 release will have major changes (unlike today
>>>> where is has no changes except removal of deprecations).
>>>>
>>>> Mike
>>>>
>>>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<ma...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>>>
>>>>>>
>>>>>> My best guess: that what this is really suggesting is that "trunk"
>>>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
>>>>>> 4.1.,
>>>>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>>>>>
>>>>>
>>>>> This is what I would like. Not sure if that's what will come from the
>>>>> current proposal or not, but seems so to me.
>>>>>
>>>>> --
>>>>> - Mark
>>>>>
>>>>> http://www.lucidimagination.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: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for
unstable Solr/Lucene development
Posted by Shai Erera <se...@gmail.com>.
I would like to think that if 3.1 is cut w/o flex (and following dependent
issues), then we will allow people to re-commit the already committed code
changes to the 3.1 branch before it is released. Then, flex et al. become
the next 4.0 and 3.1 will be the first minor stable release of 3.x w/ some
of the features that came post-flex (exercising our svn merge skills :)).
Shai
On Mon, Apr 26, 2010 at 11:01 PM, DM Smith <dm...@gmail.com> wrote:
> Assuming that the vote passed: I'm wondering where this leaves us for the
> near term? How it works in practice.
>
> There have been a lot of recent changes and flex has landed. There are a
> bunch of issues marked as 3.1 and many (most?) have decent patches.
>
> Let's suppose a 3.1 release soon. What would it be/contain and how would it
> work?
>
> -- DM
>
> On 04/26/2010 03:55 PM, Shai Erera wrote:
>
>> An interesting point was made on Version - we cannot remove it from
>> trunk just to reintroduce it when trunk is released as .0 and then
>> followed by .1 .2 "stable" releases … otherwise it would
>> appear/disappear constantly :)?
>>
>> So I guess Versuon should go away entirely?
>>
>> Shai
>>
>> On Monday, April 26, 2010, Michael McCandless<lu...@mikemccandless.com>
>> wrote:
>>
>>
>>> This is exactly the intention behind the proposal we are voting on.
>>>
>>> Big changes, that'd be destabilizing if attempted on the stable
>>> branch, would be done only on unstable (= trunk).
>>>
>>> More "normal" changes, which can still include deprecations/some back
>>> compat, would be done on the stable branch and unstable.
>>>
>>> So, eg, rather than attempt back compat for a big change like flex, we
>>> would instead do it only in unstable and it'd first become "available"
>>> in the next .0 release.
>>>
>>> By segregating the big changes away from stable we should be able to
>>> keep stronger back compat on stable. We also save our resources not
>>> building costly back compat layers that, because of their complexity,
>>> bring their own problems. Also, our release numbers are more
>>> "standard" -- the .0 release will have major changes (unlike today
>>> where is has no changes except removal of deprecations).
>>>
>>> Mike
>>>
>>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<ma...@gmail.com>
>>> wrote:
>>>
>>>
>>>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>>
>>>>
>>>>> My best guess: that what this is really suggesting is that "trunk"
>>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
>>>>> 4.1.,
>>>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>>>>
>>>>>
>>>> This is what I would like. Not sure if that's what will come from the
>>>> current proposal or not, but seems so to me.
>>>>
>>>> --
>>>> - Mark
>>>>
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for
unstable Solr/Lucene development
Posted by DM Smith <dm...@gmail.com>.
Assuming that the vote passed: I'm wondering where this leaves us for
the near term? How it works in practice.
There have been a lot of recent changes and flex has landed. There are a
bunch of issues marked as 3.1 and many (most?) have decent patches.
Let's suppose a 3.1 release soon. What would it be/contain and how would
it work?
-- DM
On 04/26/2010 03:55 PM, Shai Erera wrote:
> An interesting point was made on Version - we cannot remove it from
> trunk just to reintroduce it when trunk is released as .0 and then
> followed by .1 .2 "stable" releases … otherwise it would
> appear/disappear constantly :)?
>
> So I guess Versuon should go away entirely?
>
> Shai
>
> On Monday, April 26, 2010, Michael McCandless<lu...@mikemccandless.com> wrote:
>
>> This is exactly the intention behind the proposal we are voting on.
>>
>> Big changes, that'd be destabilizing if attempted on the stable
>> branch, would be done only on unstable (= trunk).
>>
>> More "normal" changes, which can still include deprecations/some back
>> compat, would be done on the stable branch and unstable.
>>
>> So, eg, rather than attempt back compat for a big change like flex, we
>> would instead do it only in unstable and it'd first become "available"
>> in the next .0 release.
>>
>> By segregating the big changes away from stable we should be able to
>> keep stronger back compat on stable. We also save our resources not
>> building costly back compat layers that, because of their complexity,
>> bring their own problems. Also, our release numbers are more
>> "standard" -- the .0 release will have major changes (unlike today
>> where is has no changes except removal of deprecations).
>>
>> Mike
>>
>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<ma...@gmail.com> wrote:
>>
>>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>>> My best guess: that what this is really suggesting is that "trunk"
>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>>>
>>> This is what I would like. Not sure if that's what will come from the
>>> current proposal or not, but seems so to me.
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
An interesting point was made on Version - we cannot remove it from
trunk just to reintroduce it when trunk is released as .0 and then
followed by .1 .2 "stable" releases … otherwise it would
appear/disappear constantly :)?
So I guess Versuon should go away entirely?
Shai
On Monday, April 26, 2010, Michael McCandless <lu...@mikemccandless.com> wrote:
> This is exactly the intention behind the proposal we are voting on.
>
> Big changes, that'd be destabilizing if attempted on the stable
> branch, would be done only on unstable (= trunk).
>
> More "normal" changes, which can still include deprecations/some back
> compat, would be done on the stable branch and unstable.
>
> So, eg, rather than attempt back compat for a big change like flex, we
> would instead do it only in unstable and it'd first become "available"
> in the next .0 release.
>
> By segregating the big changes away from stable we should be able to
> keep stronger back compat on stable. We also save our resources not
> building costly back compat layers that, because of their complexity,
> bring their own problems. Also, our release numbers are more
> "standard" -- the .0 release will have major changes (unlike today
> where is has no changes except removal of deprecations).
>
> Mike
>
> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>> My best guess: that what this is really suggesting is that "trunk"
>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>
>> This is what I would like. Not sure if that's what will come from the
>> current proposal or not, but seems so to me.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.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: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Chris Hostetter <ho...@fucit.org>.
: Big changes, that'd be destabilizing if attempted on the stable
: branch, would be done only on unstable (= trunk).
:
: More "normal" changes, which can still include deprecations/some back
: compat, would be done on the stable branch and unstable.
...
: By segregating the big changes away from stable we should be able to
: keep stronger back compat on stable. We also save our resources not
: building costly back compat layers that, because of their complexity,
: bring their own problems. Also, our release numbers are more
: "standard" -- the .0 release will have major changes (unlike today
: where is has no changes except removal of deprecations).
Ok .. I think i'm caught up.
My vote: +0
I like the idea changing our release/branch process so that every major
release (ie: 4.0) results in he creation of two branches: one for bug fix
release like we have now (ie: branch_4_0 where patches for releases 4.0.1
and 4.0.2 would be committed) as well as new branch for minor releases
along that major line (ie: branch_4 where patches for release in 4.1 and
4.2 would be committed instead of doing minor releases off of hte trunk
like we do now) with trunk now becoming the place where changes targeting
hte next major release (ie: 5.0, 6.0, 7.0) can be commited.
My concern is that this proposal essentially requires that our current
back compat "contract" be eliminated in favor of a looser "we'll document
what's changed and try to provide migration tools" type policy. What i
worry about is that if we do this w/o agreeing on some "higher precident"
guidelines on what exactly will be "ok" back-incompat changes to make
between major release, and what is "not ok" to hcange because it
introduces too big of a migration gap, then this could result in major
versions that are so widely differnet hte community gets fractured, with a
big chunk of users never upgrading from 4.X to 5.X because the API and
index formats are too widely different and the migration process is too
cumbersome (ahem: maven1 and maven2)
That said: I don't know that we can ever hash out where the "line which
should not be crossed" is on compat changes w/o trying stuff and seeing
what happens, and i don't personally have any better suggestions, so i'm
certianly not going to stand in the way.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
The only correction to this example is...
It's entirely possible m2 was backported to stable, and users see this
on upgrading to the next minor release.
It's only for changes that are not back-ported to stable where this
example applies, and I agree -- we have to do a strong job documenting
the migration for these trunk(unstable)-only changes.
Mike
On Tue, Apr 27, 2010 at 1:27 AM, Doron Cohen <cd...@gmail.com> wrote:
> +1
>
> I would like to note (and depict) one aspect of this change (although it is
> most probably clear to active followers of these threads).
> Deprecation warnings had been quite useful for users when upgrading to a
> *major* release.
> The voted change cancels them.
> Example follows.
> Picture the following state in the "new Lucene life cycle":
> Stable is "feeding" release 8.
> Most recent minor release is 8.4.
> Trunk will soon "feed" release 9,
> In 8.4 there is method m1(x).
> In trunk, m1(x) is renamed to m2(x,y).
> With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced.
> No deprecations!
> In stable, that is 8, no change is introduced at all - it is not possible to
> put a deprecate warning there since m2(x,y) is not there.
> Now, when 9.0 is finally cut from stable and released, we will *not* first
> cut 8.last with deprecation warning, because that usually goes with
> implementing the deprecated logic using the non-deprecated one, which is (a)
> not always feasible and (b) a burden that this whole change is trying to
> avoid.
> So, from now on, deprecation warnings would not be there to help users when
> upgrading to the next major release.
> Only documentation would guide them.
> Therefore, when committing such a change, it would be very important to
> adequately update the tbd evolving upgrade guide.
> Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Apr 27, 2010 at 2:43 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Isn't there a tool out there that automatically generates the changes in APIs?
jdiff (http://www.jdiff.org/) is pretty good.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Grant Ingersoll <gs...@apache.org>.
I think this is a pretty important point.
Isn't there a tool out there that automatically generates the changes in APIs? I seem to recall seeing one. Perhaps even IntelliJ has one built in? Obviously, one could generate the svn diffs, but that will be too verbose.
-Grant
On Apr 27, 2010, at 1:27 AM, Doron Cohen wrote:
> +1
>
> I would like to note (and depict) one aspect of this change (although it is most probably clear to active followers of these threads).
>
> Deprecation warnings had been quite useful for users when upgrading to a *major* release.
> The voted change cancels them.
> Example follows.
>
> Picture the following state in the "new Lucene life cycle":
> Stable is "feeding" release 8.
> Most recent minor release is 8.4.
> Trunk will soon "feed" release 9,
> In 8.4 there is method m1(x).
> In trunk, m1(x) is renamed to m2(x,y).
> With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced. No deprecations!
> In stable, that is 8, no change is introduced at all - it is not possible to put a deprecate warning there since m2(x,y) is not there.
> Now, when 9.0 is finally cut from stable and released, we will *not* first cut 8.last with deprecation warning, because that usually goes with implementing the deprecated logic using the non-deprecated one, which is (a) not always feasible and (b) a burden that this whole change is trying to avoid.
>
> So, from now on, deprecation warnings would not be there to help users when upgrading to the next major release.
> Only documentation would guide them.
> Therefore, when committing such a change, it would be very important to adequately update the tbd evolving upgrade guide.
>
> Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Doron Cohen <cd...@gmail.com>.
+1
I would like to note (and depict) one aspect of this change (although it is
most probably clear to active followers of these threads).
Deprecation warnings had been quite useful for users when upgrading to a
*major* release.
The voted change cancels them.
Example follows.
Picture the following state in the "new Lucene life cycle":
Stable is "feeding" release 8.
Most recent minor release is 8.4.
Trunk will soon "feed" release 9,
In 8.4 there is method m1(x).
In trunk, m1(x) is renamed to m2(x,y).
With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced.
No deprecations!
In stable, that is 8, no change is introduced at all - it is not possible to
put a deprecate warning there since m2(x,y) is not there.
Now, when 9.0 is finally cut from stable and released, we will *not* first
cut 8.last with deprecation warning, because that usually goes with
implementing the deprecated logic using the non-deprecated one, which is (a)
not always feasible and (b) a burden that this whole change is trying to
avoid.
So, from now on, deprecation warnings would not be there to help users when
upgrading to the next major release.
Only documentation would guide them.
Therefore, when committing such a change, it would be very important to
adequately update the tbd evolving upgrade guide.
Doron
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
Right, we should not require contributors to also merge down to stable
("beggars can't be choosers" ;) ).
Devs should that, and whether it's the dev who committed, or a dev who
periodically sweeps, can be worked out over time.
But Uwe should lay down the law :) Eg, we should always use "svn
merge" so the merge props are properly tracked, so that periodic
sweeping is straightforward.
Mike
On Mon, Apr 26, 2010 at 11:25 PM, Shai Erera <se...@gmail.com> wrote:
> My understanding is that "Joe Contributor" will not be forced to prepare a
> patch against "stable", but will be appreciated if he does :).
>
> The mechanics for "Joe Committer" is undecided yet. What's clear is that Joe
> cannot say "I don't care about stable for this issue, therefore I cannot
> backport it". The decision on backporting will be done per issue/patch.
> Whether it will be backported immediately (as part of that issue), or later
> on as part of a periodic stable/trunk sync, is undecided yet.
>
> A minor correction:
>>
>> they do stable or vice versa
>
> there is no "stable or vice versa" - everything must be put on trunk (unless
> it really doesn't belong there, because e.g. the API no longer exists). Many
> things will most likely get backported to stable.
>
> Shai
>
> On Tue, Apr 27, 2010 at 12:46 AM, Grant Ingersoll <gs...@apache.org>
> wrote:
>>
>> +0.9
>>
>> What are the requirements of me, "Joe Committer" and of "Joe Contributor"
>> in regards to submitting/committing patches?
>>
>> For Joe Committer, am I required to put everything on stable and trunk or
>> can I just pick trunk and if someone else wants it they do stable or vice
>> versa?
>>
>> Likewise for Joe Contributor, must I generate two patches now?
>>
>>
>> On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
>>
>> > This is exactly the intention behind the proposal we are voting on.
>> >
>> > Big changes, that'd be destabilizing if attempted on the stable
>> > branch, would be done only on unstable (= trunk).
>> >
>> > More "normal" changes, which can still include deprecations/some back
>> > compat, would be done on the stable branch and unstable.
>> >
>> > So, eg, rather than attempt back compat for a big change like flex, we
>> > would instead do it only in unstable and it'd first become "available"
>> > in the next .0 release.
>> >
>> > By segregating the big changes away from stable we should be able to
>> > keep stronger back compat on stable. We also save our resources not
>> > building costly back compat layers that, because of their complexity,
>> > bring their own problems. Also, our release numbers are more
>> > "standard" -- the .0 release will have major changes (unlike today
>> > where is has no changes except removal of deprecations).
>> >
>> > Mike
>> >
>> > On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com>
>> > wrote:
>> >> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>> >>>
>> >>> My best guess: that what this is really suggesting is that "trunk"
>> >>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>> >>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
>> >>> 4.1.,
>> >>> 4.2, etc...) happen on "more stable" branches off of the major version
>> >>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>> >>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>> >>
>> >> This is what I would like. Not sure if that's what will come from the
>> >> current proposal or not, but seems so to me.
>> >>
>> >> --
>> >> - Mark
>> >>
>> >> http://www.lucidimagination.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
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
My understanding is that "Joe Contributor" will not be forced to prepare a
patch against "stable", but will be appreciated if he does :).
The mechanics for "Joe Committer" is undecided yet. What's clear is that Joe
cannot say "I don't care about stable for this issue, therefore I cannot
backport it". The decision on backporting will be done per issue/patch.
Whether it will be backported immediately (as part of that issue), or later
on as part of a periodic stable/trunk sync, is undecided yet.
A minor correction:
> they do stable or vice versa
>
there is no "stable or vice versa" - everything must be put on trunk (unless
it really doesn't belong there, because e.g. the API no longer exists). Many
things will most likely get backported to stable.
Shai
On Tue, Apr 27, 2010 at 12:46 AM, Grant Ingersoll <gs...@apache.org>wrote:
> +0.9
>
> What are the requirements of me, "Joe Committer" and of "Joe Contributor"
> in regards to submitting/committing patches?
>
> For Joe Committer, am I required to put everything on stable and trunk or
> can I just pick trunk and if someone else wants it they do stable or vice
> versa?
>
> Likewise for Joe Contributor, must I generate two patches now?
>
>
> On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
>
> > This is exactly the intention behind the proposal we are voting on.
> >
> > Big changes, that'd be destabilizing if attempted on the stable
> > branch, would be done only on unstable (= trunk).
> >
> > More "normal" changes, which can still include deprecations/some back
> > compat, would be done on the stable branch and unstable.
> >
> > So, eg, rather than attempt back compat for a big change like flex, we
> > would instead do it only in unstable and it'd first become "available"
> > in the next .0 release.
> >
> > By segregating the big changes away from stable we should be able to
> > keep stronger back compat on stable. We also save our resources not
> > building costly back compat layers that, because of their complexity,
> > bring their own problems. Also, our release numbers are more
> > "standard" -- the .0 release will have major changes (unlike today
> > where is has no changes except removal of deprecations).
> >
> > Mike
> >
> > On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com>
> wrote:
> >> On 4/26/10 2:43 PM, Chris Hostetter wrote:
> >>>
> >>> My best guess: that what this is really suggesting is that "trunk"
> >>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
> >>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
> 4.1.,
> >>> 4.2, etc...) happen on "more stable" branches off of the major version
> >>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
> >>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
> >>
> >> This is what I would like. Not sure if that's what will come from the
> >> current proposal or not, but seems so to me.
> >>
> >> --
> >> - Mark
> >>
> >> http://www.lucidimagination.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: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Grant Ingersoll <gs...@apache.org>.
+0.9
What are the requirements of me, "Joe Committer" and of "Joe Contributor" in regards to submitting/committing patches?
For Joe Committer, am I required to put everything on stable and trunk or can I just pick trunk and if someone else wants it they do stable or vice versa?
Likewise for Joe Contributor, must I generate two patches now?
On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
> This is exactly the intention behind the proposal we are voting on.
>
> Big changes, that'd be destabilizing if attempted on the stable
> branch, would be done only on unstable (= trunk).
>
> More "normal" changes, which can still include deprecations/some back
> compat, would be done on the stable branch and unstable.
>
> So, eg, rather than attempt back compat for a big change like flex, we
> would instead do it only in unstable and it'd first become "available"
> in the next .0 release.
>
> By segregating the big changes away from stable we should be able to
> keep stronger back compat on stable. We also save our resources not
> building costly back compat layers that, because of their complexity,
> bring their own problems. Also, our release numbers are more
> "standard" -- the .0 release will have major changes (unlike today
> where is has no changes except removal of deprecations).
>
> Mike
>
> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>> My best guess: that what this is really suggesting is that "trunk"
>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>
>> This is what I would like. Not sure if that's what will come from the
>> current proposal or not, but seems so to me.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.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: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
This is exactly the intention behind the proposal we are voting on.
Big changes, that'd be destabilizing if attempted on the stable
branch, would be done only on unstable (= trunk).
More "normal" changes, which can still include deprecations/some back
compat, would be done on the stable branch and unstable.
So, eg, rather than attempt back compat for a big change like flex, we
would instead do it only in unstable and it'd first become "available"
in the next .0 release.
By segregating the big changes away from stable we should be able to
keep stronger back compat on stable. We also save our resources not
building costly back compat layers that, because of their complexity,
bring their own problems. Also, our release numbers are more
"standard" -- the .0 release will have major changes (unlike today
where is has no changes except removal of deprecations).
Mike
On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>
>> My best guess: that what this is really suggesting is that "trunk"
>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>> 4.2, etc...) happen on "more stable" branches off of the major version
>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>
> This is what I would like. Not sure if that's what will come from the
> current proposal or not, but seems so to me.
>
> --
> - Mark
>
> http://www.lucidimagination.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: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Mark Miller <ma...@gmail.com>.
On 4/26/10 2:43 PM, Chris Hostetter wrote:
> My best guess: that what this is really suggesting is that "trunk"
> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
> 4.2, etc...) happen on "more stable" branches off of the major version
> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
This is what I would like. Not sure if that's what will come from the
current proposal or not, but seems so to me.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org