lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <dmsmith...@gmail.com>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 20 May 2009 12:29:40 GMT
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
> <yonik@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message