Well ... I think that version numbers mean more than we'd like them to mean,
as people perceive them. Let's discuss the format X.Y.Z:
When X is changed, it should mean something 'big' happened - index structure
has changed (e.g. the flexible scoring work), new Java version supported
(Java 1.6) and even stuff like 'flex' which includes statements like "if you
don't want your app to slow down, consider reindexing". Such things signal a
major change in Lucene, sometimes even just policy changes (Java version
supported) and therefore I think we should reserve the ability to bump X
when such things happen.
Another thing is the index structure back-compat policy - today Lucene
supports X-1 index structure, but during upgrades of X.Y versions, your
segments are gradually migrated. Eventually, when you upgrade to 4.0 you
should know whether you have a 2.x index, and call optimize just in case if
you're not sure it's not migrated yet (if you've upgraded to 3.x).
If we start bumping up 'X' too often, we'll either need to change the X-1
policy to X-N, which will just complicate matters for users. Or we'll keep
the X-1 policy, but people will need to call optimize more frequently.
Y should change on a regular basis, and no back-compat API-wise or index
runtime-wise is guaranteed. So the Collector and per-segment searches in 2.9
could go w/o deprecating tons of API, so is the TokenStream work. Changes to
Analyzer's runtime capabilities will also be allowed between Y revisions.
Z should change when bugfixes are fixed, or when features are backported.
Really ... we rarely fix bugs on a released Y branch, and I don't expect
tons of features will be backported to a Y branch (to create a Z+1 release).
Therefore this should not confuse anyone.
So all I'm saying is that instead of increasing X whenever the API, index
structure or runtime behavior has changed, I'm simply proposing to
differentiate between really "major" changes to those that just say 'we're
not back-compat compliant'.
But above all, I'd like to see this change happening, so if I need to
surrender to the X vs. X+Y approach, I will. Just think it will create some
confusion.
BTW, w/ all that - does it mean 'backwards' can be dropped, or at least
test-backwards activated only on a branch which we decide needs it? That'll
be really great.
Shai
On Thu, Apr 15, 2010 at 10:24 AM, Earwin Burrfoot <ear...@gmail.com> wrote:
> We can remove Version, because all incompatible changes go straight to
> a new major release, which we release more often, yes.
> 3.x is going to be released after 4.0 if bugs are found and fixed, or
> if people ask to backport some (minor?) features, and some dev has
> time for this.
>
> The question of what to call major release in X.Y.Z scheme - X or Y,
> is there, but immaterial :) I think it's okay to settle with X.Y, we
> have major releases and bugfixes, what that third number can be used
> for?
>
> On Thu, Apr 15, 2010 at 09:29, Shai Erera <ser...@gmail.com> wrote:
> > So then I don't understand this:
> >
> > {quote}
> > * 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.
> >
> > {quote}
> >
> > What's different than what's done today? How can we remove Version in
> that
> > world, if we need to maintain full back-compat between 3.1 and 3.2, index
> > and API-wise? We'll still need to deprecate and come up w/ new classes
> every
> > time, and we'll still need to maintain runtime changes back-compat.
> >
> > Unless you're telling me we'll start releasing major releases more often?
> > Well ... then we're saying the same thing, only I think that instead of
> > releasing 4, 5, 6, 7, 8 every 6 months, we can release 3.1, 3.2, 3.5 ...
> > because if you look back, every minor release included API deprecations
> as
> > well as back-compat breaks. That means that every minor release should
> have
> > been a major release right?
> >
> > Point is, if I understand correctly and you agree w/ my statement above -
> I
> > don't see why would anyone releases a 3.x after 4.0 is out unless someone
> > really wants to work hard on maintaining back-compat of some features.
> >
> > If it's just a numbering thing, then I don't think it matters what is
> > defined as 'major' vs. 'minor'. One way is to define 'major' as X and
> minor
> > X.Y, and another is to define major as 'X.Y' and minor as 'X.Y.Z'. I
> prefer
> > the latter but don't have any strong feelings against the former. Just
> > pointing out that X will grow more rapidly than today. That's all.
> >
> > So did I get it right?
> >
> > Shai
> >
> > On Thu, Apr 15, 2010 at 8:19 AM, Mark Miller <markrmil...@gmail.com>
> wrote:
> >>
> >> I don't read what you wrote and what Mike wrote as even close to the
> >> same.
> >>
> >> - Mark
> >> http://www.lucidimagination.com (mobile)
> >> On Apr 15, 2010, at 12: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
> >>
> >
> >
>
>
>
> --
> 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
>
>
