lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: Lucene's default settings & back compatibility
Date Tue, 19 May 2009 13:14:13 GMT
On Tue, May 19, 2009 at 16:56, Grant Ingersoll <> wrote:
> There's a difference between std. coding practices and purposefully putting
> in lots of if checks to solve back compatibility issues that are created in
> order to satisfy some naming convention.  Given the length of time between
> releases, we could easily call every new release a major version and we
> wouldn't be all that different from most commercial projects.
> I've said it before and I'll say it again.  Given the time between Lucene
> releases (at least 6 mos. for minor releases and 1+ year for majors) we have
> _PLENTY_ of time to let users know what is coming and plan accordingly.   By
> being so dogmatic about back compatibility, I believe we are making it
> harder to innovate and harder for new people to contribute and we keep cruft
> around for way too long.  (How the heck is a new contributor supposed to
> keep track of all the things that went into Lucene for the past 1.5 years?)
>  I'm not saying we should throw back compat. out the window, I'm just saying
> we should take it more on a case by case basis, with the default, obviously,
> being to favor back compatibility.  The large majority of users  (I'd
> venture to say well north of 95% of them) will be able to deal with minor
> API changes every 6 to 8 months, especially if we are more proactive about
> communicating them to java-user@ and in CHANGES.

> I think you missed the point.  The problem lies in releasing 2.4's settings
> and those settings are wrong.  Using your example, say Settings24 was messed
> up and set trackMaxScore to true when it should have been false (mistakes
> happen).  It gets released in 2.9 as the settings for 2.4 back
> compatibility.  We then realize our mistake.  How do you fix it?  You can't
> just set it to false, b/c now you have users who are depending, potentially,
> on the _wrong_ version.  So, now you have to deprecate it and come out with
> a "new" Settings2.4 called something else.

> Sorry, I'd rather read CHANGES.  It is the one place we all make sure to
> enter our changes.  People aren't as good about javadocs, especially
> accessors where the name is "self explanatory".  Plus it has a link to a
> JIRA issue.

> Also, how useful is it going to be to have 30 or 40 (hundreds?) accessors on
> a single Settings object?  So, then, the logical thing to do is to split it
> up and have some nested way of doing things.  And then people will be tired
> of having to programmatically set all the values, so they will create a
> config/properties file that does it.  But, because we don't like
> dependencies, we will re-invent how that works.  After it's all said and
> done, you end up having re-invented IOC.

God, let this man be heard. Please.
I mean, I agree with all said above, maybe in a bit less tactful way.

Kirill Zakharenko/Кирилл Захаренко (
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message