|
|
Subscribe / Log in / New account

openSUSE Leap's backward version jump

The openSUSE project has announced that the release following openSUSE Leap 42 will be called openSUSE Leap 15. "SUSE have decided that their next version of SLE will be 15, not 13. Upon learning of SUSE's plans the Board and Leap release team have been considering our options. This included ignoring the changes to SLE and releasing Leap 43 as planned, at the cost of the link between SLE versions and Leap versions. 45 was also considered, as were some frankly hilarious ideas that made me worry about my own sanity and that of my fellow contributors. After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version."


From:  Richard Brown <RBrownCCB-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org>
To:  opensuse-project <opensuse-project-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org>, "opensuse-announce-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org" <opensuse-announce-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org>, oS-fctry <opensuse-factory-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org>
Subject:  openSUSE Leap's Next Major Version Number
Date:  Sat, 22 Apr 2017 13:37:48 +0200
Message-ID:  <CAA0b23wvFs5-NDkwh5MOgdian2mvOZB7zxrjNhFisN1C7-9=og@mail.gmail.com>

Hi all,

On behalf of the openSUSE Board and Leap Release Management I am
pleased to announce the next version of openSUSE Leap after 42.3 will
be:

openSUSE Leap 15

As with Leap 42.x, minor releases are expected annually for at least 3
years, so you can expect a Leap 15.1 to follow, then 15.2 and onwards.

Obviously this is quite a dramatic change from the current version
number of 42.x, so I will explain what justifies this change in some
detail below.

First, some history. When we started openSUSE Leap, the version number
was an issue that needed addressing. openSUSE at that time was at
13.2, but SUSE Linux Enterprise (SLE) was at 12 and heading towards 12
SP1.

As the main unique selling point of Leap compared to every other
distribution is the fact it is based on SLE sources. We wanted to
reflect that in the version number.
This was particularly important when you consider that a major version
in SLE really means something ("major architectural changes from the
last version are introduced here") whereas minor versions/service
packs have a very different message ("easy to upgrade to, no major
workflow breaking changes"). Leap follows a similar philosophy, so we
wanted a versioning scheme to reflect SLEs.

But openSUSE had already had versions starting with 12, so we couldn't
sync up with SLE. This is where 42.x came from. It gave us the
opportunity to establish a relationship with SLE versions (SLE Version
+ 30 = Leap Version), reflect the major/minor nature of Leap releases,
and avoid clashes with version numbers we'd already used.
The choice of 42 doubled as a humorous nod to hitchhikers guide to the
galaxy and the first version numbers of SuSE Linux and YaST (4.2 and
0.42 respectively).

The plan was therefore for the next version of Leap to be 43 with it's
release aligned with SLE 13, followed by Leap 43.1 (with SLE 13 SP1),
Leap 43.2 (w. SP2), etc

However, like all good plans, things change.

SUSE have decided that their next version of SLE will be 15, not 13.

Upon learning of SUSE's plans the Board and Leap release team have
been considering our options.
This included ignoring the changes to SLE and releasing Leap 43 as
planned, at the cost of the link between SLE versions and Leap
versions.
45 was also considered, as were some frankly hilarious ideas that made
me worry about my own sanity and that of my fellow contributors.

After considering the pros and cons of all the options however, the
decision has been that Leap 15 will be our next version.

SUSE's decision to skip SLE 13 and 14 gave us a perfect opportunity to
sync up with SLE versions like we always wanted to originally with
Leap. It's an opportunity we will not be able to take so easily a few
years from now if we continued with Leaps current versioning.

There are only a few packages in our distribution that reference the
42.x versioning, and they should be easily handled as part of a zypper
dup, so we are not concerned about this decision impacting users
upgrading.

We are aware that this decision could be a minor annoyance for users
of Leap with configuration management tools like saltstack and puppet,
but the long term opportunity to simplify such configuration (by being
able to treat SLE and Leap similarly) outweighed our desire to avoid a
'one-time' effort for people currently handling the overly complicated
situation caused by Leap being at 42.x and SLE being at 12 SPx.

Packagers should be able to look forward to an easier time of things
as a result of this change. We intend to deprecate the
0%{leap_version} macro and simplify the current complex nest of
suse_version and sle_versions that can make it very frustrating to
build packages appropriately for Tumbleweed, Leap and SLE.

0%{suse_version} should continue to be available as a simple indicator
of the major version of Leap & SLE for packagers (eg, 0%{suse_version}
== 1500 is the expected value for SLE 15 and Leap 15 and all of their
minor versions/service packs).

0%{sle_version} should remain as a more precise indicator when
packagers need to handle specific versions of Leap and SLE (eg.
0%{sle_version} == 150000 is the expected value for SLE 15 & Leap 15,
with 150100 being the expected value for SLE 15 SP1 & Leap 15.1)

0%{is_opensuse} will continue for those times when packagers need to
distinguish between Leap and SLE even though they will now more
closely share their versions.

The above examples and what the future suse_version number will be for
Tumbleweed is not yet final, so expect to see emails from ludwig in
opensuse-factory-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org when they are set.

Thanks to everyone involved in this so far, I'm looking forward to
seeing what we make out of Leap 15, and even though I cross-posted
this I would like to ask that any followup conversation is kept to the
opensuse-project-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org thread.

Regards,

Richard Brown
on behalf of the openSUSE Board
-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org
To contact the owner, email: opensuse-project+owner-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org


to post comments

openSUSE Leap's backward version jump

Posted Apr 24, 2017 19:15 UTC (Mon) by trazor (guest, #115278) [Link] (10 responses)

Typical Backwards Broken & Retarded (BBR) news from the Linux crowd. I sent Ubuntu emails for years about how Unity was "broken and retarded" and never received a reply. Now it looks like OpenSUSE is on the same dumb path to OS failure. As a Computer Scientist, I think it's funny how no one in the Linux crowd has passed CSCI-010 for idiots!

No.

Posted Apr 24, 2017 19:27 UTC (Mon) by corbet (editor, #1) [Link] (9 responses)

If your messages had the same tone as this post, I can see why they might have been ignored.

One can certainly question the wisdom of this particular decision without engaging in this sort of low-level personal attack. Please avoid such attacks on LWN in the future.

No.

Posted Apr 24, 2017 20:25 UTC (Mon) by nix (subscriber, #2304) [Link] (5 responses)

Technically this *is* a retardation -- the number is going backwards. However... SunOS did the same in 1992 with Solaris 2, and it was not exactly lethal to them (though everyone poked fun at them for it), what with Solaris more or less owning the dotcom boom eight years later.

Maybe this is a sign that SuSE will rule the Third Dotcom Boom in the year 2025!

No.

Posted Apr 24, 2017 22:06 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

Or perhaps it's a sign that in the year 2025, Oracle will buy SuSE and proceed to drive it into the ground?

No.

Posted Apr 25, 2017 10:27 UTC (Tue) by drag (guest, #31333) [Link]

Hopefully Suse will be the one buying Oracle. Along with Redhat finally buying IBM and killing of AIX and Canonical buying Microsoft.

Not

Posted Apr 25, 2017 12:14 UTC (Tue) by jengelh (guest, #33263) [Link] (1 responses)

>However... SunOS did the same in 1992 with Solaris 2

That is a rename, a new product line. In all the years, the *SunOS* version never went backwards (cf. wikipedia Solaris article, history table there).

Not

Posted Apr 26, 2017 19:43 UTC (Wed) by nix (subscriber, #2304) [Link]

True enough, as uname on a Solaris box will tell you. :)

No.

Posted Apr 26, 2017 11:48 UTC (Wed) by paulj (subscriber, #341) [Link]

The API accessible SunOS version did _not_ go backwards. Solaris 2 was versioned as SunOS 5.x, where x was the minor version of the Solaris release. E.g. Solaris 2.0 was SunOS 5.0, Solaris 11 is SunOS 5.11.

Further, Solaris was pretty different (in Unix lineage terms) to SunOS. SunOS was BSD derived. Solaris was AT&T System V derived.

No.

Posted Apr 25, 2017 1:58 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

I thought the comment was just a mildly amusing parody. Attached to a fairly lightweight article (this is just about version numbers, after all), surely we can let it pass.

Just version numbers?

Posted Apr 25, 2017 10:57 UTC (Tue) by NAR (subscriber, #1313) [Link] (1 responses)

Well, although it's just version numbers, this can break any script that checks for e.g. version newer then 40 or anything that tries to sort releases...

Just version numbers?

Posted Apr 26, 2017 21:19 UTC (Wed) by cyphar (subscriber, #110703) [Link]

Any such script was broken in the first place :). openSUSE has rpm macros specifically for this purpose.

openSUSE Leap's backward version jump

Posted Apr 26, 2017 1:40 UTC (Wed) by xorbe (guest, #3165) [Link]

Why would you number an OS with something that immediately makes it look two years old. Take a page from car manufs and use SLE 18, problem solved.

openSUSE Leap's backward version jump

Posted Apr 26, 2017 10:51 UTC (Wed) by lbt (subscriber, #29672) [Link]

I think it's a really sensible engineering decision that properly brings the technical issue to here-and-now and hence doesn't introduce technical debt to the future.

A while back they had a good design (alignment) that couldn't be done properly. They went with the second best approach. Suddenly they get a chance - probably just one chance - to do it right. Not zero cost but not that bad. So they did it right. Kudos!!

oh and if you think "how silly, we used to be able to rely on versions increasing in a numerical way" then I suggest you read this page and rethink what you thought you knew :

https://en.opensuse.org/openSUSE:Build_Service_cross_dist...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds