2010/4/15 Shai Erera <ser...@gmail.com>: > 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.
I prefer X.Y, ie, changes to Y only is a minor release (mostly bug fixes but maybe small features); changes to X is a major release. I think that's more "standard", ie, people will generally grok that 3.3 -> 4.0 is a major change but 3.3 -> 3.4 isn't. So this proposal would change how Lucene releases are numbered. Ie, the next release would be 4.0. Bug fixes / small features would then be 4.1. > Index back compat should be maintained between major releases, like it is > today, STRUCTURE-wise. No... in the proposal, you must re-index on upgrading to the next major release (3.x -> 4.0). I think supporting old indexes, badly (what we do today) is not a great solution. EG on upgrading to 3.1 you'll immediately see a search perf hit since the flex emulation layer is running. It's a trap. It's this freedom, I think, that'd let us drop Version entirely. It's the back-compat of the index that is the major driver for having Version today (eg so that the analyzers can produce tokens matching your old index). EG Terrier seems to have the same requirement -- note the bold "All indexes must be rebuilt": http://terrier.org/docs/current/whats_new.html Also, Lucene isn't a primary store (like a filesytem or a database). We expect that your "true" content still lives somewhere else. So why do we go to such great lengths to keep the index format for so long...? > BTW, w/ all that - does it mean 'backwards' can be dropped, or at least > test-backwards activated only on a branch which we decide needs it? That'll > be really great. I think the stable branches (2.x, 3.x) would have backwards tests created the moment they are branched, to make sure as we fix bugs / backport minor features we don't break back compat, along that branch. I don't think we need the .Z part of a release numbering -- our numbers would look like most other software projects. 3.0 is a major release, 3.1, 3.2, 3.3 fix bugs / add minor features, etc. If flex were done in this world I would've finished it alot faster! A huge amount of time went into the cross back compat emulation layers (pre-flex APIs and pre-flex index). > Also, we will still need to maintain the Backwards section in CHANGES (or > move it to API Changes), to help people upgrade from release to release. I think we'd create a migration guide to explain how apps migrate to the next major release (this is what other projects do), eg like this: http://community.jboss.org/wiki/Hibernate3MigrationGuides#A42 > Unless you're telling me we'll start releasing major releases more often? I think this is mostly orthogonal? We could still do major releases frequently or rarely with this model... however, it would give us more freedom to do major releases frequently (vs today where every major release sets a scary back-compat-burden stake in the ground). > 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 I think the minor releases on the stable branch (3.1, 3.2, 3.3) would be mostly bug fixes, but maybe also minor features if contributor's/developer's had the itch to make them available on the stable (3.x) branch. How much dev happens on the stable branch can be largely determined by itch... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
