Luis Alves wrote:
> Mark Miller wrote:
>> Mark Miller wrote:
>>  
>>> Michael Busch wrote:
>>>      
>>>>  Why will just saying once again "Hey, let's just release more often"
>>>> work now if it hasn't in the last two years?
>>>>
>>>>  Mich
>>>>           
>>> I don't know that we need to release more often to take advantage of
>>> major numbers. 2.2 was released in 07 - we could have just released 2.9
>>> right after 2.2 rather than also releasing 2.3 and 2.4. The number of
>>> releases between major releases is self imposed.
>>>
>>>       
>> And actually - even 2.9, which took so long, didn't have to. A .9
>> release could be very fast and only done as a stepping stone to the next
>> major release. The pain of how long everything took was just self
>> imposed. We could have moved to 3.0 years ago easily if someone has
>> suggested so. The truth is, all the deprecation complain stuff only
>> recently reached a boil - so noone suggested moving to the next major
>> version faster long enough ago. When they did, we jumped from 2.4 to
>> 2.9. And the 2.9 was a huge release - but again, it didn't have to be.
>> It could have been a formality - Grant was arguing at one point that it
>> should have been.
>>
>>   
> I don't see much difference in have frequent major releases or
> frequent minor releases,
> if they share same backwards-compatibility policy.
>
> If you have 4 major releases per year 4.0 , 5.0, 6.0 and 7.0, or four
> minor release
> 3.2, 3.3, 3.4, 3.5.
> From the user perspective is not going to help that much since, since
> moving from 4.0 to 6.0
> will have the same cost of moving from 3.2 to 3.4, if the
> backwards-compatibility is similar in
> major releases and minor-releases and the time between release is the
> same.
>
> What I like in Michael proposal is that it gives the user a chance to
> move between sequential minor releases
> without breaking the code, if you follow the process of cleaning your
> code from deprecated calls.
> I would hope this rule would also apply to 3.9 to 4.0 if these are
> sequential releases.
This is already the case. Except it easier to follow because you know it
happens on the .9 to .0 release.
>
> If you see what lucene community is doing with 2.4->2.9->3.0 this is
> actually Michael proposal
> but now will be the rule instead of the exception that was done just
> for 3.0 major release.
No - its a rule now. Its happens every time we go from .9 -> .0
>
> Lucene could have gone from 2.4 to 3.0, without having any releases in
> between, since it was a major
> release and there was no need to be backward-compatible, but that
> would have created major code migration
> headaches.
No it couldn't have. Thats would have been against the current back
compat policy. There isn't much difference between the two options -
except that one is clearer about the when and where - it happens on the
.9 -> .0 move - with the this proposed way, it happens on some minor
release -
to know which, you have to follow along. And possibly different
deprecations would be removed on different minor releases - making the
whole thing a
mess of a lot harder than using major number points.
>
> Option B) allows developers to remove old code more quickly and does
> not force the lucene community to create
> major releases for code clean up. It gives flexibility and guarantees
> the users with a clean upgrade path.
Thats the only reason we create major releases now. It has nothing to do
with features. So doing it more often doesn't hurt anything.
>
> I also propose that we should also apply this rule between the last
> minor release of previous major release
> and next major release, just as it was done for 2.4->2.9->3.0.
That rule already exists.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>


-- 
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to