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

Reply via email to