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
