openSUSE:Versioning scheme

Current versioning scheme

The current scheme uses two numbers: a major one and a minor one. Every release, we increase the minor number, except after some random time when we increase the major number and reset the minor to 0.

The current versioning scheme is the continuation of the scheme that was used since the early days of S.u.S.E. Linux (some versions went up to .4, some just up to .2 before increasing the major version number - the last ones ended at .3).

Example: 11.0, 11.1, 11.2, 11.3, 12.0.

Benefits of our current versioning scheme (or of not changing)

No need to educate people about the new scheme and avoid potential confusion.

Issues with our current versioning scheme

It is unclear to many people why it works this way, and many people aren't sure if what's after 11.3 is 11.4 or 12.0.

The jump from 11.3 to 12.0 means for many people that there will be big visible changes in the distribution, while the changes between 11.3 and 12.0 are of the same order of magnitude as the ones from 11.2 to 11.3. There's nothing that stays the same between 11.x and 11.x+1: Branding, base system etc. are all changed at will. Software developers expect some consistency between 11.x and 11.x+1 that is not there.
- Not always has the bump of the major version been going in line with greater changes. It seems that .3 is also always the last minor to be used and that a major bump is imminent afterwards (SUSE Linux 6.4 was the last .4).

It's an occasion to break the link between openSUSE and SLE versions: people expect SLE 12 to be based on openSUSE 12.1 because SLE 11 was based on openSUSE 11.1 and SLE 10 was based on SuSE Linux 10.x. Another confusion that can be made is that SLE 11 SP1 can be named SUSE 11.1 by some people, which could be understood as openSUSE 11.1.

Not directly a benefit, but if the project decides to adopt a strategy, then changing the versioning scheme at the same time is a way to send a stronger signal about the change in focus of our project.

Users expect that a .0 release is buggy and that a .3 release is extremely stable. Or going back: 11.2 was good, 11.0 was not good - so I use 12.2 again. But there's nothing in our processes that forces us to make a certain release more stable than others.

Other existing version schemes

Fedora-like: 12, 13, 14, 15. (a single number)

Mandriva-like/Gentoo-like: 2011.0, 2011.1 or 2011.1, 2011.2 or 11.1, 11.2. ($year.$number)

Ubuntu-like: 11.3, 11.11, 12.7. ($year.$month)

It's worth pointing out that the very first versions of S.u.S.E. Linux were using a $month/$year versioning scheme. See http://en.wikipedia.org/wiki/OpenSUSE#Version_history

Potential issues if changing the versioning scheme

%suse_version in our packaging: this is a macro that is used to easily know for which version of openSUSE a package is built. It's important that we're able to do something like %suse_version < $version, in a way that would work with both the new scheme and the old scheme. So we need to have 11.3 < $nextversion.
- Actually the only thing that is required is that %suse_version monotonically increases. There is no strict requirement that it needs to relate to any particular version.

Versioning scheme vs Code name

From a marketing perspective, it's possible to use a version or a code name to talk about a product. Both approaches exist and are widely used.

For reference, we already have a scheme for code names: the shades of green. 11.3 is Teal, 11.2 was Emerald.

For more information on shades of green: