lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Proposal for changing the backwards-compatibility policy
Date Tue, 16 Jun 2009 16:16:25 GMT
Also, much shorter text to read :)

You're right, Michael's is 484 words, mine was 691. But in my defense, I did
offer two more changes, that were later brought up on this thread (summing
to 563 words) :).

Anyway, I'm glad it's kept alive and hopefully things will change.

Shai

On Tue, Jun 16, 2009 at 7:09 PM, Mark Miller <markrmiller@gmail.com> wrote:

> 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
>> http://www.nabble.com/Re%3A-Lucene%27s-default-settings---back-compatibility-p23792927.htmlwith
+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 <buschmic@gmail.com<mailto:
>> buschmic@gmail.com>> 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<buschmic@gmail.com>
>>> <mailto:buschmic@gmail.com> wrote:
>>>
>>>
>>>>    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: java-dev-unsubscribe@lucene.apache.org<mailto:
>>>> java-dev-unsubscribe@lucene.apache.org>
>>>>    For additional commands, e-mail: java-dev-help@lucene.apache.org<mailto:
>>>> java-dev-help@lucene.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
View raw message