On Sun, 23 Aug 2009, 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 :)
It's a clean break with the past, well worth the release effort.
There is no such thing as a no-op release. I'm sure people will find bugs or
usability issues with 2.9 days after it's released. Rapidly fixing some of
these in 3.0 would be a nice gesture.
- remove deprecations
- fix important/obvious bugs reported since 2.9
- move a few 1.5 things in like StringBuilder to cast 1.5 use in stone (and
set expectations accordingly)
- release 3.0
In other words, 3.0 is really a 2.9.1 bug fix release with a few extra
things requiring the major version increment.
Andi..
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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
