Re: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development

[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
>
>

Re: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development

[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