On 10/16/09 10:27 AM, Steven A Rowe wrote:
On 10/16/2009 at 2:58 AM, Michael Busch wrote:
B) best effort drop-in back compatibility for the next minor version
number only, and deprecations may be removed after one minor release
(e.g. v3.3 will be compat with v3.2, but not v3.4)
This is only true on a per-feature basis. For example, if feature A is deprecated in
v3.1, and feature B is deprecated in v3.2, then v3.3 will be "compat" with v3.2
only as far as feature B is concerned; feature A will no longer be present in v3.3.
Under these circumstances, saying "v3.3 will be compat with v3.2" with no
caveats sounds to me like false advertising.
Steve
That is true. Further above in my mail I said "simple jar drop-in
replacement will not be possible anymore with almost every Lucene
release"and I should have made it clearer in the sentence you pointed
out too: with option B you can only be sure that you can switch to a new
version (e.g. v3.3) without the need to recompile if your app compiled
against the previous version (v3.2) without deprecation warnings.
Let me point out that in any case, no matter if we pick A or B, the
committers will try what they can to make upgrading as easy as possible.
If you look back in Lucene's history I think we always did that,
especially with index file format (I don't think we ever required
reindexing to upgrade). Now in terms of API backwards-compatibility even
with option B it doesn't mean we'll go crazy with deprecations and
removals. We don't *have* to remove an API in 3.3 only because it was
deprecated in 3.2.
Let me give you another example: the current TokenStream API changes
were very big, and the TokenStream API is very central and often
extended by users. Now with the current backwards-compatibility policy
we decided to remove the old API entirely in 3.0. If we had policy B in
place already, we'd be able wait until 3.1 and give users more
transition time. But we certainly don't want to wait until 4.0 - it may
be surprising for many how much (complicated) code is currently in
Lucene to support compatibility for this and other features.
Even if we try to make major releases more often, how often do people
realistically expect this will happen? Lucene 2.0 was released in May
2006. The 2.9 release that is now available still supports every single
public and protected API from the last 3 1/2 years. We're saying for
about 2 years now that we should make releases more often in general.
The committers always vote +1 if someone says "let's release more
often". But if didn't happen so far. We could now analyze the reasons
and how we could change that. But frankly I think partially it's just
the nature of things: there are many different people, with different
schedules, working on different features of different sizes and Lucene
has different components. Getting all this aligned isn't so easy. Why
will just saying once again "Hey, let's just release more often" work
now if it hasn't in the last two years?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
