I'll defer to the collective wisdon of folks like rmuir & simon & uwe &
mccandless about when the major new APIs & features like codecs &
docvalues are stable and vetted enough to consider releasing, and i'll
defer to miller & yonik about when the solr cloud update stuff is ready;
but i think we'd be letting down a lot of users if we tried to release
something called "4.0" that didn't have those things in it.
i'm also +1 to everything quoted below...
: I haven't tried the trunk/4.0 stuff, so maybe I'm out of line, but how
: about a public alpha first. It would have appropriate disclaimers
...an alpha off of trunk even before doing beta(s) off of a 4x_branch
would be a good wake up call to folks that Lucene 4.0 is not a myth and
that people need to start paying attention and speak up if they see any
major api/doc problems or weird bugs they haven't brought up because they
just assumed it would get fixed eventually (be nice to fix as much as we
can on trunk before branching so we don't have to do a bunch of anoying
merges)
: > 2. copy trunk to branch_4x and call it our 'stable branch' (even
: > though it isn't, not yet).
: > 3. trunk is now 5.x and open for scary changes like trunk is today.
: > 4. eventually, when its right, we issue alpha or beta or real release
: > off branch_4x for 4.0
...
: > 1. we need multiple implementations to flush out any assumptions in
: > the abstract APIs.
: > 2. we need to ensure multiple impls actually work for backwards
: > compatibility to actually work in the future.
... +1 to all that
As for this comment...
: > 1. we decide that 3.6 (no reason to call it 3.9?) should be the last
: > minor release on 3.6, lets try to make a nice 3.6,... we can then
: > issue bugfixes like 3.6.1, 3.6.2, ...
..i'm not sure that we need to paint ourselves into that particular
corner.
once we make a 4x branch, the only hard line we *have* to stand behind is
not to make file format changes to 3x -- that doesn't mean there can't be
minor feature releases like 3.7, etc... (it's unlikely that there should
ever be a need for them, but there's no reason to forbid it -- just like
there's nothing stoping us from putting out a 2.10 release right now if
some previously silent but large user base of the 2.x APIs comes a long
clammoring for a backport of some small feature)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
