Andreas Jaeger wrote:
Let me summarize what my opinion is: * A version scheme needs to be documented to avoid these kind of discussions - we failed so far in this arena * A version number scheme needs to be predictable - we fail with your proposal basing SLE12 on openSUSE 12.1. My counterproposal to increase directly after SLES12 to 13.0 is better here... * I would prefer to have a superior version scheme but I haven't seen it brought forward. If some great idea comes up, let's do it. But I agree with let's not change it just to change it ;)
Generally (and non-marketing-related) speaking, version numbers are used to distinguish products, typically wrt features and inter-operatibility. Dot-releases are expected to inter-operate without a hitch, have less bugs than minorversion-1, and overall be "a little better"(R) that minorversion-1. No new or earth-shattering features are expected. For people with only a couple of systems at home, the version number is of little use (apart from marketing), for people with multiple systems in production, version numbering, both for openSUSE, mysql and Apache is important. When you're running in production, _any_ change is a risk, so upgrading is not done just because a new openSUSE release is available. Instead, changes are planned, customers notified, fallback plans made etc., and the upgrade is done slowly (if necessary or desired) on a weekend, most often Saturday night :-( Regarding Andreas' proposal wrt documentation and predictability, those are certainly fine qualities, but the one we have been sorely missing is adherence. If we are to continue with major.minor (my favourite, but mostly out of habit), we just have define what makes up a) a major release and b) a minor ditto. I'll be happy to write a draft proposal. If we chose not to use a major.minor scheme (for instance because we cannot coordinate changes in a suitable way), I propose the 11.3++ release becomes openSUSE 12.0, the following 12.1, then 12.2 etc. With a proviso that the major number 12 cannot change without 1) significant base system changes and 2) board approval. -- Per Jessen, Zürich (19.9°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org