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
