The great leap backward

OpenSUSE Leap is an interesting hybrid distribution; its core packages come from the slow-and-stable SUSE Linux Enterprise (SLE) release, but those packages are replaced or supplemented by much newer software where desired. The current (and only) openSUSE Leap release was originally based on SLE 12 and openSUSE 13.1. The project had an immediate problem in that it needed to come up with a version number for this new distribution; in the end, it did what any of us would have done and chose 42. The current release is openSUSE Leap 42.2.

Eventually even an enterprise distribution gets around to a new major release; that is expected to happen with SLE sometime in 2018. A new SLE release will have a new version number, of course. The working expectation on the openSUSE side was that the next SLE would be SLE 13, and that openSUSE leap would, continuing with the SLE+30 formula, release openSUSE Leap 43 based on that release.

But, as openSUSE board chair Richard Brown recently noted, plans can change. In its wisdom, SUSE management decided that the next SLE release would not be SLE 13; it seems that SLE 15 has greater market appeal. The reasons behind the decision have not escaped the smoke-filled room in which it was made, but it has been speculated that the purpose was to avoid the number 13, which is seen as being unlucky in many parts. Similarly, 14 contains a 4, an ill-starred number in parts of Asia, so it was out of the running. 15, being a triangular, hexagonal, and pentatope number (among other things), was the obvious choice.

Parents in the US, who often acquire much gray hair at the prospect of their children getting driving permits at the age of 15, may well not consider that number to be especially auspicious either. It seems that Europe-based SUSE is less concerned about that particular fear, unreasonable as that may seem.

Naturally, using 43 as the version number for the next openSUSE Leap release is now entirely out of the question; there is no point in even talking about it. So the openSUSE board retired to its rather smaller smoke-filled room to find a solution to this existential problem. The triumphant result was then announced by Brown: openSUSE Leap 42.x would be followed by openSUSE Leap 15. That is when the mailing lists erupted with complaints about this decision; it seems that the inherent rightness of 15 isn't entirely obvious to the community as a whole.

There were complaints that this decision was made in private, without the prior involvement of the community. As anybody who has watched our community for any time knows, had the version-number question been posed to the mailing list as a whole, the result would have certainly been a much more polite conversation converging on an obvious consensus that all participants would then support wholeheartedly. It always works that way, after all, why should this time be any different?

Unsurprisingly, some community members are horrified by the idea of a software release having a lower version number than its predecessor; they think that both humans and scripts might become confused in a world where the first derivative of version numbers is not always positive. But they fail to appreciate the full mathematical complexity of openSUSE version numbers, of which the headline number (15 in this case) is only the most visible. Consider, for example, the suse_version number found within the spec files used to build openSUSE packages.

The old openSUSE 13.1 release sets suse_version to 1310, while the slightly less old 13.2 release (from 2014) has 1320. The much newer OpenSUSE Leap 42 release, having branched off before openSUSE 13.2, uses 1315 for suse_version — another example of what we might call, in this day and age, "alternative incrementing". OpenSUSE Leap 15 is expected to use 1500, restoring order to that part of the universe, but at the cost of creating potential confusion elsewhere. The leading-edge Tumbleweed release, which should have the highest version number, will not be content to remain at its current 1330; Brown worries that numerous scripts will "explode" when Tumbleweed inevitably leapfrogs Leap to something over 1500. Throw in sle_version (tied to the underlying SLE version) and leap_version (giving the precise Leap version — but only in 42.2) and one might argue that a backward step in the major version number is the least of the project's numbering issues.

That said, this decision has set up another existential crisis for the future: what happens when the SLE 42 release comes out and openSUSE Leap is faced with reusing a version number — a deed seen as being even more foul than going backward? Brown shrugged off this problem, saying that, at the current release rate, SLE 42 isn't due for over 100 years. There should, he implied, be time for plenty of other flame wars before that one needs to heat up.

Brown's math is neglecting an important fact, though: SLE just skipped over two numbers, and might well be expected to do the same thing again in the next century. After all, 16 is a power of two, and all those zeroes might make some potential customers nervous. It's also the atomic number of sulfur; best to just skip it. Italians see 17 as an exceptionally ill-starred number. 18 is voting age in much of the world, and nobody has had luck with voting recently, so that one should be avoided too. 19 is suspiciously prime, but might yet prove acceptable pending further research. And so on; SLE 42 may come far sooner than anybody expects.

Be that as it may, it would appear that minds are made up, and that calls to "kick the board" and continue with the existing versioning scheme, reasonable as they may be, will go unheeded. OpenSUSE may have leaped before it looked, but whether that happened now or back when "42" was chosen is unclear. The good news is that our community is resilient, and even openSUSE Leap's version-number decisions will fade into history to a well-earned place alongside events like the merging of devfs and the invention of JavaScript. The flames may be high but, once again, that's a reliable indication that the stakes are low.