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>
> 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>luc...@mikemccandless.com> wrote:
>>>
>>>> On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey
>>>> < <mar...@rectangular.com>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>
>>>> java-dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: <java-dev-h...@lucene.apache.org>
>>>> java-dev-h...@lucene.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Kirill Zakharenko/?????? ????????? ( <ear...@gmail.com>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>
>>> java-dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: <java-dev-h...@lucene.apache.org>
>>> java-dev-h...@lucene.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: <java-dev-unsubscr...@lucene.apache.org>
>> java-dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: <java-dev-h...@lucene.apache.org>
>> java-dev-h...@lucene.apache.org
>>
>
>
