lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Back Compatibility
Date Tue, 22 Jan 2008 20:45:01 GMT

: I guess I am suggesting that instead of maintaining the whole major/minor
: thing (not including file format) that we relax a bit and say that any give
: feature we choose to remove or add has to go through two release cycles, which
: according to your averages, would equal just over 1 year's time.  If people
: can't adapt to a coming change that was announced a year ago, then I have to
: wonder why they need to upgrade at all. (OK, that is a little strong, but...)

as someone else pointed out somewhere in this thread (reading it all at 
once i'm lossing track) this will make it harder for people to understand 
how much effort it will be to go from version 3.4 to 3.5 ... is that a 
drop in replacement?

Perhaps the crux of the issue is that we as a community need to become 
more willing to crank out "major" releases ... if we just released 3.0 and 
now someone came up with the "Magic" field type and it's really magically 
and we want to start using it but it's not backwards compatibly -- well i 
guess are next release just needs to be called 4.0 then ... it's clear 
from the version number that this is a significant change, evne if it does 
wind up getting released 3 months after v3.0

: And again, I still think the more pertinent issue that needs to be addressed
: is how to better handle bugs in things like Tokenization, etc. where people
: may have dependencies on broken functionality, but haven't fully comprehended
: that they have such a dependency.  I don't think those fixes/deprecations
: should have to wait for a major release.

I think situations like this are the one place where using system 
properties to force broken/legacy behavior would really make sense ... we 
fix the code so all "new" users get the correct/better behavior, and we 
document in the CHANGES.txt that the behavior has changed.  the code is 
drop in compatile for anyone who isn't relying on broken behavior, and if 
you are you can set a system proberty to foce the old behavior.
(caveat: to support the few cases people have mentioned where you can't 
set system properties easily (applets i think?) a static method should be 
provided as well, so if you need old broken behavior *AND* you can't use 
system properties you just have to add one line of code to your app)

: Does anyone have experience w/ how other open source projects deal with this?


The best solution I've seen is to support multiple "stable" branches.  
we've talked about doing that before, but there haven't been any features 
anyone has steped up to backport to an older version since that 
discussion. (probably because we've done such a good job of making it easy 
for people to upgrade)

As i mentioned elsewhere in this thread: i worry about the community 
fragementing if we raise the bar on upgrading in order to lower the bar on 
development ... having multiple "stable" branches seems like it could also 
fragment the community very easily... people using 3.2.X releases not 
being able to interact/help with people using 2.4.Y on the user list 
because certain things work drasitcly differnetly.

backporting bug fixes is one thing, but i'm leary of backporting new 
features and performance improvements (not that i would object to anyone 
doing so ... i'm just scared of where it might lead)


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

View raw message