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
headaches.
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: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
