Wow this is *very* similar! :)
On 6/16/09 4:29 AM, Shai Erera wrote:
Since I proposed the same changes
(http://www.nabble.com/Re%3A-Lucene%27s-default-settings---back-compatibility-p23792927.html),
I can only give my +1 to all 4 :).
On the other thread I also proposed to change the policy around
changing default settings. But maybe we should take it one step at a time.
Shai
On Tue, Jun 16, 2009 at 1:37 PM, Michael Busch <busch...@gmail.com
<mailto:busch...@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-unsubscr...@lucene.apache.org
<mailto:java-dev-unsubscr...@lucene.apache.org>
For additional commands, e-mail: java-dev-h...@lucene.apache.org
<mailto:java-dev-h...@lucene.apache.org>
