: 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? Poorly. 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) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
