OK it sounds like a single global actsAsVersion is too problematic. So how about, for cases where back compat default settings are important (analyzers, query scoring changes, etc.) we add actsAsVersion as a mandatory ctor argument to those classes (deprecating the other ctors)? We would do this on demand, the first time a class needs to change its default behavior.
For example, in 2.9 we'd like sorting by field to not return score by default. So, we'd add actsAsVersion to IndexSearcher's ctors, and IndexSearcher then looks at the version it should emulate and sets the defaults correctly. New users would not use the deprecated API, and would pass Versions.LUCENE_LATEST. Existing users on upgrading would see that they need to explicitly set their compatibility level (and, we'd default it to the last version so that back-compat users don't see anything break on upgrading). Mike On Fri, May 22, 2009 at 9:45 AM, Grant Ingersoll <gsing...@apache.org> wrote: > Perhaps it is wise to take a step back before we play all of these "what if" > games... > > I think the best way forward is to simply ask ourselves, when confronted > with an actual issue, is what is the cost of back compat. for this issue and > then address it on a case by case basis, with a bias towards maintaining > back compat if it is not too burdensome. Too burdensome is a judgment call > for the contributors and committers. > > As for the Settings vs. static actAs stuff, I really am on the fence. They > both have their downsides, so I'm inclined to punt. Frankly, I think if > someone wants 2.4.1 functionality and we're on 2.9 or even 3.0, but some of > the new features available on 2.9, then they should backport the patches. I > don't think the burden should be on us to have the trunk support every > single setting that was ever available on a given 2.x release given the time > frames we operate on The fact is, we are obsessing over the name of the > release, when the more important factor is the time it takes to make the > release. If we released once a month, I'd be inclined otherwise, but for > the reality we are in, I'm almost ready we to say we should just chuck the > whole major minor thing and say we go the MS way: Lucene 2009 and then have > service pack releases for just that year's major release (I realize, of > course, they likely have internal versions, etc. but maybe not) > > -Grant > > --------------------------------------------------------------------- > 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
