Yeah, the only difference now is that we can remove deprecated APIs. And
I guess we add nothing.
Which is, as Micahel has said, is goofy.
3.0 will be 2.9 like 1.9 was 2.0. Without deprecations.
Not a big deal at all, but I find it goofy too.
- Mark
Michael Busch wrote:
> From a backwards-compatibility point of view, nothing really.
>
> Michael
>
> On 6/16/09 8:59 AM, Yonik Seeley wrote:
>> So under this proposal, what's the difference between a major and minor release?
>>
>> -Yonik
>> http://www.lucidimagination.com
>>
>>
>>
>> On Tue, Jun 16, 2009 at 6:37 AM, Michael Busch<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
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: 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
|