lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@osafoundation.org>
Subject Re: Proposal about Version API "relaxation"
Date Wed, 14 Apr 2010 22:34:23 GMT

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
> <lucene@mikemccandless.com> wrote:
>> On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey
>> <marvin@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
>
>
> -- 
> Kirill Zakharenko/?????? ????????? (earwin@gmail.com)
> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
> ICQ: 104465785
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
View raw message