On Sun, 23 Aug 2009, Mark Miller wrote:
I'm still +1 on calling this 3.0 as I was before when you mentioned it.
Its a wakeup call that the upgrade is a bit major in certain areas.
In either case - 3.0 is more representative of what this release is IMO.
I also think we should allow new features in 3.0 if we release this as 2.9.
Sure, as long as they don't go against the "fast turnaround" goal.
As for version number, I think that the pending release number should be 2.9
(as in 3.0 with lots of back compat and 1.4 baggage), and the next one be
3.0, following shortly (say, three weeks later) after 2.9.
As for backwards compatility, I think there should be a blanket amnesty on
backwards compatibility breaks for 2.9 - 3.0 - 3.0.x,y,z - 3.1 so that the
APIs can be made sane, consistent and free of back compat compromises. It is
difficult to get all of this right in one release, for sure. Exposing faster
releases to more users and setting expectations accordingly would be a win
for the next few releases, I think.
Just my $0.02...
Andi..
- Mark
Michael McCandless wrote:
Right, this (you can jump to 2.9, fix all deprecations, then easily
move to 3.0 and see no deprecations) is my understanding too, but I
don't see what's particularly useful about that. It does produce a
Lucene release that has zero deprecated APIs (assuming we remove all
of them), but I don't think that's very important. Also, it's extra work
having to do a "no-op, except for deprecations removal and generics
addition" release :)
Vs say taking our time creating 3.0, letting it have real features,
etc.
Or, another option would be to simply release 3.0 next. After all,
there are some seriously major changes in this release, compilation
breakage, etc. ... things you'd more expect (of "traditional"
software) in a .0 release. And, then state clearly that all
deprecated APIs in 3.0 will be removed in 3.1. While this is
technically a change to our back-compat policy, it's also just a
number-shifting game since it would just be a rename
(2.9 becomes 3.0; 3.0 becomes 3.1).
Mike
On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<markrmil...@gmail.com> wrote:
Michael McCandless wrote:
On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<markrmil...@gmail.com> wrote:
I forgot about this oddity. Its so weird. Its like we are doing two
releases on top of each other - it just seems confusing.
I'm also not wed to the "fast turnaround" (remove deprecations, switch
to generics) 3.0 release.
We could, instead, take out time doing the 3.0 release, ie let it
include new features too.
I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
but I can't remember it nor find it now...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
I thought the motivation was to provide a clean upgrade path with the
deprecations - you move to 2.9 and move from all the deprecated methods
- then you move to 3.0 and your good with no deprecations. I'd guess the
worry is that new features in 3.0 would add new deprecations and its not
quite so clean?
Personally, I think thats fine though. New deprecations will come in 3.1
anyway. You can still move everything in 2.9, and then move to 3.0 - so
what if something else is now deprecated? You can move again or wait for
3.9 to move ...
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
