On Tue, May 19, 2009 at 16:56, Grant Ingersoll <gsing...@apache.org> 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/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
