![](https://seccdn.libravatar.org/avatar/184f2936f5d39b27534f4dd7c4d15bfb.jpg?s=120&d=mm&r=g)
Vincent Untz wrote:
(I'm setting Mail-Followup-To to opensuse-project, since that's where this discussion should happen, but I agree we might want to wait for the end of the strategy discussion)
Le samedi 03 juillet 2010, à 09:10 +0200, Martin Schlander a écrit :
Fredag den 2. juli 2010 17:05:06 skrev Andreas Jaeger:
On Friday 02 July 2010 16:56:04 Thomas Schmidt wrote:
Shouldn't we call this 12.0? Reassigning the features afterwards would be additional work.
Naming of the next release is a separate discussion we might have. I'm opposed to both 11.4 and 12.0 and look forward to great proposals,
Let's not get too creative here. No funky codenames! :-)
We actually have code names, and it's the shades of greens. 11.3 is Teal. We just don't advertize this -- yet. (I think we should).
The codenames are visible on the console. Personally I think codenames ought to remain internal, project-only - like today, but _perhaps_ with a bit more awareness/usage. I really don't like the hip Ubuntu naming and I'd have to use a dictionary to find out what "teal" is. (same goes for most of the Ubuntu names).
We should go for a simple numbering scheme, that doesn't cause the confusion that the old one has (a lot of people give different meanings to the numbers, even though they don't mean a thing - other than of course x.1 meaning "unusually buggy").
Either do it the Fedora way. openSUSE 12, 13, 14 etc.
Or the Mandriva way 2011.0, 2011.1, 2012.0 etc.
(Or the Ubuntu way, except that it doesn't work well with the next version which would be 11.03: 11.03, 11.12, 12.07)
What is wrong with the existing scheme? Two things that come to mind: 1) it's just a continuation of the SuSE Linux numbering 2) there's no implied meaning of '.x' I propose we name the next openSUSE "openSUSE 1.0". Wrt 2), I don't know if we really need/want an implied meaning of the '.x', but maybe we can come up with an idea in the context of strategy. (one thought: even = desktop release, odd = server release?)
One technical side of the decision that was pointed out in an earlier discussion is that we want to keep some suse_version compatibility. That means we still need to have, somehow, 11.3 < $nextversion.
That did occur to me, but I'm unaware of the details. -- Per Jessen, Zürich (25.1°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org