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 Tue, 27 Oct 2009 22:43:57 GMT
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.

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.

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

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.

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.

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

View raw message