Rob OpenSuSE wrote:
2008/12/22 James Tremblay aka SLEducator
: Extra possible "win" - "long term support "could more easily be moved to x.3 releases citing the x.1\x.2 as support levels for x.0. with the bonus side effect of reducing update channel bandwidth. i.e. security only on x.0 then nothing unless x.1 is applied (This is nothing new to major software vendors, can't tell you how many times I've heard "we only support that product at x.1.2.3, please upgrade.") then x.3s could also be easily translated to SLEs. It seems a waste that SuSE built YaST with all this functionality to not let openSUSE benefit from it's heritage.
That would also have a nice consistent story for the version numbers.
If most of the destabilising and experimental stuff, came into an X.0 release, I don't think it's really viable to just have security fixes.
So actually it'd be better to say that the X.3 version is the "stable", and have X.0, X.1 and X.2 getting updated for bug fixes, and new package versions, with the difficulty of introducing new features increasing greatly as the X.3 release approaches.
Most openSUSE users will probably track the newer code then, but those who want to avoid the dislocation of the more developmental versions, can stop at X.3 until they feel comfortable, installing X+1.2 for example and then getting updates to X+1.3.
How if X.3 is basically the same as SLED/SLES avoid the problem of internal competition, if it has LTS?
I was thinking, LTS would only be the time between x.3s plus one dev cycle (approx. 24 months). so on the release of the next x.0 LTS would end.
OTOH if X.3 is freely copiable and effectively evaluation, developers would be encouraged to use it, and then later on their customers, would be deploying SLED/SLES most likely? An easy switch to get LTS, or to subscribe to updates, when X.3 is past it's short term support, might increase revenue.
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org