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 <markrmil...@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 <busch...@gmail.com<mailto: >> busch...@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<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> >>>> >>>> >>>> >>>> >>> >>> >> >> >> > > -- > - Mark > > http://www.lucidimagination.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
