lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Alves <>
Subject Re: Proposal for changing Lucene's backwards-compatibility policy
Date Wed, 28 Oct 2009 01:07:26 GMT
Mark Miller wrote:
> 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.
Thanks for the reply,

If that is the case, and major releases become more frequent maybe
every 6-12 months. I don't see many differences.

But there needs to be some forced push for these shorter major release 
to allow for code clean cycles to also be sorter.

Is there any ideas how to push the community,
to make major release cycles shorter?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message