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
