I like the idea of settings however it is implemented. With the
blurring of core and contrib in the repackaging of Lucene, the issue
of backward compatibility becomes more difficult. (maybe, I'm
imagining problems where they don't exist.)
My concern with any of these mechanisms: codifying past behavior. What
would be the expectation and policy regarding the keeping of such
settings? Do these now become deprecated? Do we keep a 2.1 settings
when we are releasing 2.4?
There is an even simpler solution, using existing policy: Frequent
releases.
Would this be a big issue if we had frequent releases?
To go from 2.0 to 3.0 there is a 2.9 release, where the difference
between the 2.9 release and the 3.0 release is the removal of
deprecations. (Though with this release, it will be a bit bigger as it
will also require Java 5.)
Every time we approach a release, there is a flurry of activity and
the release gets pushed, for all practical purposes, indefinitely.
Pushed to absurdity: Only have x.0 (perhaps x.0.1) and x.9 releases.
That is don't have a x.1 minor release. And have releases once a week,
so that 2 times a month we have a major release. So twice a month we
can break API compatibility and once a month we can break index
compatibility.
The stability of the API over time is important to users. Having
infrequent releases with a great product is a plus. (I'm really glad
as I'm still stuck using Java 1.4!) Having the bridge via deprecation
to newness is a great transitional help.
IMHO, the real challenge it to manage the release process. Managing
that will help manage backward compatibility.
If you were to look at the schedule for Fedora, Eclipse,
OpenOffice, ..., you'd find that each has a release plan with distinct
stages. At each stage there is a release (testing/alpha/beta/RC1/
RC2/...) As the release process is being entered, generally a release
branch is created. New development continues on trunk and something of
perceived value may be ported to the branch. At some point there is a
feature freeze and only bug fixes are accepted on the release branch.
Having a branch with parallel development is a very strong
encouragement to have a quick release, as it is a pain to have it.
-- DM
On May 20, 2009, at 7:22 AM, Michael McCandless wrote:
On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley
<yo...@lucidimagination.com> wrote:
Right, that's exactly why I want to fix it (only one behavior
allowed
and so for all of 2.* we must match the 2.0 behavior).
I meant one jar per per-jvm gives you one behavior (as is the case
now).
But by setting a static actsAs version number, you could get a 2.*
jar
to behave as if it were 2.0, even as behaviors evolve.
So I think you're suggesting something like this: when you use Lucene,
if you want "latest and greatest" defaults, do nothing.
If instead you want defaults to match a particular past minor release,
you must call (say) LuceneVersions.setVersion(VERSION_21).
Any place inside Lucene that has defaults that need to vary by version
would then check this, and act accordingly.
I absolutely love the simplicity of this solution (far simpler than
*Settings classes). It would achieve what I'm aiming for, which is to
always be free on every minor release to set the defaults for new
users to the latest & greatest.
But:
1) It means any usage of Lucene inside the JRE must share that same
version default
2) It's a change to our back-compat policy, in that it requires the
app to declare what version compatibility it requires.
On #1, maybe this is in fact just fine, since as you pointed out
that's de-facto what we have today; it's just that the "actsAs" is
hardwired to 2.0 for all 2.x releases.
On #2, I think shifting the burden onto those apps that do in fact
need strict back-compat on upgrading, to have to set the actsAs is a
good change to our policy. After all, we think such users are the
minority and putting the burden on new users of Lucene seems
unreasonable.
So net/net I'm +1!
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
