Also, we will still need to maintain the Backwards section in CHANGES (or move it to API Changes), to help people upgrade from release to release. Just pointing that out as well.
Shai On Thu, Apr 15, 2010 at 7:05 AM, Shai Erera <ser...@gmail.com> wrote: > Ahh ... a dream finally comes true ... what a great way to start a day :). > +1 !!! > > I have some questions/comments though: > > * Index back compat should be maintained between major releases, like it is > today, STRUCTURE-wise. So apps get a chance to incrementally upgrade their > segments when they move from 2.x to 3.x before 4.0 lands and they'll need to > call optimize() to ensure 4.0 still works on their index. I hope that will > still be the case? Otherwise I don't see how we can prevent reindexing by > apps. > ** Index behavioral/runtime changes, like those of Analyzers, are ok to > require a reindex, as proposed. > > So after 3.1 is out, trunk can break the API and 3.2 will have a new set of > API? Cool and convenient. For how long do we keep the 3.1 branch around? > Also, it used to only fix bugs, but from now on it'll be allowed to > introduce new features, if they maintain back-compat? So 3.1.1 can have > 'flex' (going for the extreme on purpose) if someone maintains back-compat? > > I think the back-compat on branches should be only for index runtime > changes. There's no point, in my opinion, to maintain API back-compat > anymore for jars drop-in, if apps will need to upgrade from 3.1 to 3.1.1 > just to get a new feature but get it API back-supported? As soon as they > upgrade to 3.2, that means a new set of API right? > > Major releases will just change the index structure format then? Or move to > Java 1.6? Well ... not even that because as I understand it, 3.2 can move to > Java 1.6 ... no API back-compat right :). > > That's definitely a great step forward ! > > Shai > > > On Thu, Apr 15, 2010 at 1:34 AM, Andi Vajda <va...@osafoundation.org>wrote: > >> >> On Thu, 15 Apr 2010, Earwin Burrfoot wrote: >> >> Can't believe my eyes. >>> >>> +1 >>> >> >> Likewise. +1 ! >> >> Andi.. >> >> >>> On Thu, Apr 15, 2010 at 01:22, Michael McCandless >>> <luc...@mikemccandless.com> wrote: >>> >>>> On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey >>>> <mar...@rectangular.com> wrote: >>>> >>>> Essentially, we're free to break back compat within "Lucy" at any time, >>>>> but >>>>> we're not able to break back compat within a stable fork like "Lucy1", >>>>> "Lucy2", etc. So what we'll probably do during normal development with >>>>> Analyzers is just change them and note the break in the Changes file. >>>>> >>>> >>>> So... what if we change up how we develop and release Lucene: >>>> >>>> * A major release always bumps the major release number (2.x -> >>>> 3.0), and, starts a new branch for all minor (3.1, 3.2, 3.3) >>>> releases along that branch >>>> >>>> * There is no back compat across major releases (index nor APIs), >>>> but full back compat within branches. >>>> >>>> This would match how many other projects work (KS/Lucy, as Marvin >>>> describes above; Apache Tomcat; Hibernate; log4J; FreeBSD; etc.). >>>> >>>> The 'stable' branch (say 3.x now for Lucene) would get bug fixes, and, >>>> if any devs have the itch, they could freely back-port improvements >>>> from trunk as long as they kept back-compat within the branch. >>>> >>>> I think in such a future world, we could: >>>> >>>> * Remove Version entirely! >>>> >>>> * Not worry at all about back-compat when developing on trunk >>>> >>>> * Give proper names to new improved classes instead of >>>> StandardAnalzyer2, or SmartStandardAnalyzer, that we end up doing >>>> today; rename existing classes. >>>> >>>> * Let analyzers freely, incrementally improve >>>> >>>> * Use interfaces without fear >>>> >>>> * Stop spending the truly substantial time (look @ Uwe's awesome >>>> back-compat layer for analyzers!) that we now must spend when >>>> adding new features, for back-compat >>>> >>>> * Be more free to introduce very new not-fully-baked features/APIs, >>>> marked as experimental, on the expectation that once they are used >>>> (in trunk) they will iterate/change/improve vs trying so hard to >>>> get things right on the first go for fear of future back compat >>>> horrors. >>>> >>>> Thoughts...? >>>> >>>> Mike >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>>> >>>> >>>> >>> >>> >>> -- >>> Kirill Zakharenko/?????? ????????? (ear...@gmail.com) >>> >>> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 >>> ICQ: 104465785 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > >
