lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Proposal for changing the backwards-compatibility policy
Date Tue, 16 Jun 2009 16:09:45 GMT
I would guess you hit what I call "thread fatigue" by the time you 
summed that up :)

Michael hasn't been around for a bit - perhaps it was easier for him to 
spawn a new thread.

Also, much shorter text to read :)

Shai Erera wrote:
> Ahh ... I wish I had finished 

> with +1 of my own. Guess that's what was missing to get it to closure :).
> Shai
> On Tue, Jun 16, 2009 at 7:03 PM, Michael Busch < 
> <>> wrote:
>     I'd suggest to treat a runtime change like an API change (unless
>     it's fixing a bug of course),
>     i.e. giving a warning, providing a switch, switching the default
>     behavior only after a major
>     or minor release was around that had the warning/switch.
>      Michael
>     On 6/16/09 8:54 AM, Earwin Burrfoot wrote:
>>     Oh yes! Again!
>>     +1
>>     One point is missing. What about incompatible behavioral changes that
>>     do not touch API and file format?
>>     Like posIncr=0 at the first token in stream, or analyzer fixes, or
>>     something along these lines.
>>     Are we free to introduce them in a minor release without warning, or
>>     are we going to warn one release before the change, or do we provide
>>     old-behaviour switches that are deprecated since their birth, or we
>>     keep said switches for a couple of major releases?
>>     On Tue, Jun 16, 2009 at 14:37, Michael Busch<> <>
>>>     Probably everyone is thinking right now "Oh no! Not again!". I admit I
>>>     didn't fully read the incredibly long recent thread about
>>>     backwards-compatibility, so maybe what I'm about to propose has been
>>>     proposed already. In that case my apologies in advance.
>>>     Rather than discussing our current backwards-compatibility policy
>>>     again, I'd like to make here a concrete proposal for changing the policy
>>>     after Lucene 3.0 is released.
>>>     I'll call X.Y -> X+1.0 a 'major release', X.Y -> X.Y+1 a
>>>     'minor release' and X.Y.Z -> X.Y.Z+1 a 'bugfix release'. (we can later
>>>     use different names; just for convenience here...)
>>>     1. The file format backwards-compatiblity policy will remain unchanged;
>>>       i.e. Lucene X.Y supports reading all indexes written with Lucene
>>>       X-1.Y. That means Lucene 4.0 will not have to be able to read 2.x
>>>       indexes.
>>>     2. Deprecated public and protected APIs can be removed if they have
>>>       been released in at least one major or minor release. E.g. an 3.1
>>>       API can be released as deprecated in 3.2 and removed in 3.3 or 4.0
>>>       (if 4.0 comes after 3.2).
>>>     3. No public or protected APIs are changed in a bugfix release; except
>>>       if a severe bug can't be changed otherwise.
>>>     4. Each release will have release notes with a new section
>>>       "Incompatible changes", which lists, as the names says, all changes that
>>>       break backwards compatibility. The list should also have information
>>>       about how to convert to the new API. I think the eclipse releases
>>>       have such a release notes section.
>>>     The big change here apparently is 2. Consider the current situation:
>>>     We can release e.g. the new TokenStream API with 2.9; then we can
>>>     remove it a month later in 3.0, while still complying with our current
>>>     backwards-compatibility policy. A transition period of one month is
>>>     very short for such an important API. On the other hand, a transition
>>>     period of presumably >2 years, until 4.0 is released, seems very long
>>>     to stick with a deprecated API that clutters the APIs and docs. With
>>>     the proposed change, we couldn't do that. Given our current release
>>>     schedule, the transition period would at least be 6-9 months, which
>>>     seems a very reasonable timeframe.
>>>     We should also not consider 2. as a must. I.e. we don't *have* to
>>>     deprecate after one major or minor release already. We could for a
>>>     very popular API like the TokenStream API send a mail to java-user,
>>>     asking if people need more transition time and be flexible.
>>>     I think this policy is much more dynamic and flexible, but should
>>>     still give our users enough confidence. It also removes the need to
>>>     do things just for the sake of the current policy rather than because
>>>     they make the most sense, like our somewhat goofy X.9 releases. :)
>>>     Just to make myself clear: I think we should definitely stick with our
>>>     2.9 and 3.0 plans and change the policy afterwards.
>>>     My +1 to all 4 points above.
>>>     -Michael
>>>     ---------------------------------------------------------------------
>>>     To unsubscribe, e-mail: <>
>>>     For additional commands, e-mail: <>

- Mark

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message