+1 On Apr 14, 2010, at 5:22 PM, Michael McCandless 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
