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

Reply via email to