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