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
