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@opensuse.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@opensuse.org thread.
Regards,
Richard Brown on behalf of the openSUSE Board
Il 22/04/2017 13:37, Richard Brown ha scritto:
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
15 ? Seriously ? So absurd that is hard to debate...
Daniele.
On Samstag, 22. April 2017 13:45:22 CEST Daniele wrote:
Il 22/04/2017 13:37, Richard Brown ha scritto:
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
15 ? Seriously ? So absurd that is hard to debate...
Daniele.
How about openSUSE Leap $(sha256sum $ISOIMAGEFILENAME) :-(
Am 22.04.2017 um 22:38 schrieb Mathias Homann:
On Samstag, 22. April 2017 13:45:22 CEST Daniele wrote:
Il 22/04/2017 13:37, Richard Brown ha scritto:
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
15 ? Seriously ? So absurd that is hard to debate...
Daniele.
How about openSUSE Leap $(sha256sum $ISOIMAGEFILENAME) :-(
Can I get a version with my name?? :D
On 04/22/2017 04:50 PM, Karl Sinn wrote:
Can I get a version with my name?? :D
Sure. Just change your name to "openSUSE". ;)
Am 22.04.2017 um 22:58 schrieb James Knott:
On 04/22/2017 04:50 PM, Karl Sinn wrote:
Can I get a version with my name?? :D
Sure. Just change your name to "openSUSE". ;)
:D
On 04/22/2017 01:37 PM, Richard Brown wrote:
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
What have you been smoking? Remove at least the useless "Leap" substring again to make clear that introducing 42.x was also just a big mistake.
All your explanations about "why 15" are completely useless. The only nondebatable sense of version numbers is that there are ordered. It's not possible to justify randomly ordered version numbers.
cu, Rudi
Il 22/04/2017 14:47, Rüdiger Meier ha scritto:
On 04/22/2017 01:37 PM, Richard Brown wrote:
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
What have you been smoking? Remove at least the useless "Leap" substring again to make clear that introducing 42.x was also just a big mistake.
All your explanations about "why 15" are completely useless. The only nondebatable sense of version numbers is that there are ordered. It's not possible to justify randomly ordered version numbers.
cu, Rudi
+1 15, at this point, is worst then 42. We cannot change things because someone wake up with "wonderful" ideas in mind. Daniele.
P.S. I'll keep the discussion in @factory because there are more interessed users..
* Daniele kailed@kailed.net [04-22-17 11:27]:
Il 22/04/2017 14:47, Rüdiger Meier ha scritto:
On 04/22/2017 01:37 PM, Richard Brown wrote:
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
What have you been smoking? Remove at least the useless "Leap" substring again to make clear that introducing 42.x was also just a big mistake.
All your explanations about "why 15" are completely useless. The only nondebatable sense of version numbers is that there are ordered. It's not possible to justify randomly ordered version numbers.
cu, Rudi
+1 15, at this point, is worst then 42. We cannot change things because someone wake up with "wonderful" ideas in mind.
next openSUSE will be OPENsuse :)
P.S. I'll keep the discussion in @factory because there are more interessed users..
not really the place, s/b opensuse. factory is to tech help/conversation
On Sat, 22 Apr 2017 11:54:21 -0400 Patrick Shanahan wrote:
15, at this point, is worst then 42. We cannot change things because someone wake up with "wonderful" ideas in mind.
next openSUSE will be OPENsuse :)
you beat me, I was Just about to propose openSUSE lEap 15 :-)
regards, Dieter
On Saturday, 22 April 2017 12:37:48 BST Richard Brown wrote:
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
Oh dear.... This continual rebranding, renumbering and renaming only causes confusion, it looks like no-one knows what they are doing especially after the big-sell of Leap and 42. The same happened with the rebranding of KDE5 to Plasma when everyone expects common sense to continue with KDE5 as its got so much history and its logical to go from KDE4 to KDE5.
I guess it keeps someone busy.
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@opensuse.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@opensuse.org thread.
Regards,
Richard Brown on behalf of the openSUSE Board
On Samstag, 22. April 2017 14:53:40 CEST ianseeks wrote:
On Saturday, 22 April 2017 12:37:48 BST Richard Brown wrote:
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
Oh dear.... This continual rebranding, renumbering and renaming only causes confusion, it looks like no-one knows what they are doing especially after the big-sell of Leap and 42. The same happened with the rebranding of KDE5 to Plasma when everyone expects common sense to continue with KDE5 as its got so much history and its logical to go from KDE4 to KDE5.
my wife was just looking over my shoulder.... her comment: "If they can't even consistent about the version number scheme, what about the software?"
Richard Brown composed on 2017-04-22 13:37 (UTC+0200):
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
:-(
I get why 15, so won't try to argue against it even though I don't like it.
What I don't get is why to keep the Leap part. I didn't like it before, but will like it less, with the reason for it effectively lost on going down from 42 to 15. I won't type or speak the superfluous term, just as I already don't.
If I had my druthers, next would be Opensuse 1501, 1502, 1503, 1601, 1602, 1603, 1701, etc.; or 151, 152, 153, 161, 162, 163, 171, etc.
On 22/04/17 09:27 AM, Felix Miata wrote:
Richard Brown composed on 2017-04-22 13:37 (UTC+0200):
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
:-(
I get why 15, so won't try to argue against it even though I don't like it.
So we had 12.x ... 13.x and in reality 42 was 14. Now we're back on sequence with 15.x. Yes, I get it. What's after that? "Fish 77"?
What I don't get is why to keep the Leap part.
Oh, that was easy, it was a leap from 13, over a whole pile of other numbers, couple of decades worth. "Bound" had other connotations, but has the same basic meaning. "Spring Jump" might seem, well, seasonal. So we leaper from 13 all the way to 42 in a single bound.
Now we're regressing, again in a single bound.
Make perfect sense, doesn't it?
If I had my druthers, next would be Opensuse 1501, 1502, 1503, 1601, 1602, 1603, 1701, etc.; or 151, 152, 153, 161, 162, 163, 171, etc.
Yes, we should definitely stick with numbers. Not animals, not cypto-dates, not alliterations. A nice, regular monotonic sequence. Keep the mathematicians happy.
On 04/22/2017 04:16 PM, Anton Aylward wrote:
On 22/04/17 09:27 AM, Felix Miata wrote:
If I had my druthers, next would be Opensuse 1501, 1502, 1503, 1601, 1602, 1603, 1701, etc.; or 151, 152, 153, 161, 162, 163, 171, etc.
Yes, we should definitely stick with numbers. Not animals, not cypto-dates, not alliterations. A nice, regular monotonic sequence. Keep the mathematicians happy.
I agree, numbers are good enough as long as they are randomly ordered to keep to our scheme consistent.
cu, Rudi
Il 22/04/2017 11:24, Rüdiger Meier ha scritto:
On 04/22/2017 04:16 PM, Anton Aylward wrote:
On 22/04/17 09:27 AM, Felix Miata wrote:
If I had my druthers, next would be Opensuse 1501, 1502, 1503, 1601, 1602, 1603, 1701, etc.; or 151, 152, 153, 161, 162, 163, 171, etc.
Yes, we should definitely stick with numbers. Not animals, not cypto-dates, not alliterations. A nice, regular monotonic sequence. Keep the mathematicians happy.
I agree, numbers are good enough as long as they are randomly ordered to keep to our scheme consistent.
cu, Rudi
Sorry if I permitting myself to express my humble opinion among a bunch of literally "Genius Developers" as many of you are, but why you don't adopt similar names schemes as Windows does:
I.E.: Windows 10 build(xxxx)
We will have in this way an "OpenSUSE Leap build (what-you-prefer-to-put-in-here)" to track the update version of the release.
Or, in the evenience that by naming the "Windows" word could raise some irritations in this M.L., why you don't adopt the Tumbleweed simpler scheme of release naming also for Leap?
marco@linux-turion64:~> cat /etc/os-release
NAME="openSUSE Tumbleweed" # VERSION="20170419" ID=opensuse ID_LIKE="suse" VERSION_ID="20170419"
So we will get "OpenSUSE Leap version 201704"
Then since I have understood that Lap has a cycle-of-life of three years, the next Leap would be:
"OpenSUSE Leap version 202004"
:-)
Have a nice week-end!
On 2017-04-22 16:58, Marco Calistri wrote:
So we will get "OpenSUSE Leap version 201704"
Oh, it was one of the proposals we voted for years ago, without the leap part. It did not win, we selected the traditional X.Y, where Y would be 1,2,3, with the exception of 11.4 for I don't remember what reason.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Il 22/04/2017 13:58, Carlos E. R. ha scritto:
On 2017-04-22 16:58, Marco Calistri wrote:
So we will get "OpenSUSE Leap version 201704"
Oh, it was one of the proposals we voted for years ago, without the leap part. It did not win, we selected the traditional X.Y, where Y would be 1,2,3, with the exception of 11.4 for I don't remember what reason.
The important is to avoid a war and keep receiving the updates ;-)
Cheers, - -- Marco Calistri
LA: Winston your quite drunk! WC: Madame your quite ugly. In the morning I will be sober where as you will still be ugly! -- Sir Winston and Lady Astor
On 2017-04-22 15:27, Felix Miata wrote:
Richard Brown composed on 2017-04-22 13:37 (UTC+0200):
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
:-(
I get why 15, so won't try to argue against it even though I don't like it.
I see the reasoning, but... :-? I'm flabbergasted. I don't know what to say. I'll better shutup ;-)
(my neighbours heard a loud WHAAT!?) X'-)
What I don't get is why to keep the Leap part. I didn't like it before, but will like it less, with the reason for it effectively lost on going down from 42 to 15. I won't type or speak the superfluous term, just as I already don't.
+1 for leaving the "leap" away. It's one word to much and it gives no additional information to the version number.
Karl
On 2017-04-22 22:36, Karl Sinn wrote:
What I don't get is why to keep the Leap part. I didn't like it before, but will like it less, with the reason for it effectively lost on going down from 42 to 15. I won't type or speak the superfluous term, just as I already don't.
+1 for leaving the "leap" away. It's one word to much and it gives no additional information to the version number.
It does... it is an hybrid of SLE and TW. It gets the core (30%?) from one and the rest from the other. As that doesn't change, the "leap" word has to stay.
Am 22.04.2017 um 23:45 schrieb Carlos E. R.:
On 2017-04-22 22:36, Karl Sinn wrote:
What I don't get is why to keep the Leap part. I didn't like it before, but will like it less, with the reason for it effectively lost on going down from 42 to 15. I won't type or speak the superfluous term, just as I already don't.
+1 for leaving the "leap" away. It's one word to much and it gives no additional information to the version number.
It does... it is an hybrid of SLE and TW. It gets the core (30%?) from one and the rest from the other. As that doesn't change, the "leap" word has to stay.
I don't even know what this means (and I don't wanna know, I just wanna keep using the latest version of the software in the most stable version possible). And I guess that most openSuSE users, even if they have heard these sentences, don't know what this means in detail. Especially new users won't have a clue about this and don't need to know. So the version number should be just fine.
Specialists like you, who do know what this means, they know anyway that it is like it is => again the name won't change anything.
On 2017-04-22 23:59, Karl Sinn wrote:
Am 22.04.2017 um 23:45 schrieb Carlos E. R.:
+1 for leaving the "leap" away. It's one word to much and it gives no additional information to the version number.
It does... it is an hybrid of SLE and TW. It gets the core (30%?) from one and the rest from the other. As that doesn't change, the "leap" word has to stay.
I don't even know what this means (and I don't wanna know, I just wanna keep using the latest version of the software in the most stable version possible).
Well, that's the point about Leap, you will not.
The core of the distro is at the same versions as the related SLE version, and thus /may/ not be updated in 3 or 5 years.
If you want it simpler: some packages in Leap 42.3 /may/ be the same version as in Leap 42.1.
I don't even know what this means (and I don't wanna know, I just wanna keep using the latest version of the software in the most stable version possible).
Well, that's the point about Leap, you will not.
The core of the distro is at the same versions as the related SLE version, and thus /may/ not be updated in 3 or 5 years.
If you want it simpler: some packages in Leap 42.3 /may/ be the same version as in Leap 42.1.
OK, I reread the lifetime information of openSuSE. https://en.opensuse.org/Lifetime
You're right, I don't always get the absolutely newest version of a software, but therefor I get versions which are longer tested and therefor supposedly more stable than tumbleweed. Fine for me.
Still I don't need the word "leap" in the version numbering ;)
On 2017-04-23 00:30, Karl Sinn wrote:
If you want it simpler: some packages in Leap 42.3 /may/ be the same version as in Leap 42.1.
OK, I reread the lifetime information of openSuSE. https://en.opensuse.org/Lifetime
You're right, I don't always get the absolutely newest version of a software, but therefor I get versions which are longer tested and therefor supposedly more stable than tumbleweed. Fine for me.
Still I don't need the word "leap" in the version numbering ;)
Yes, you do. Or we do. Because Leap is different than the previous stable versions up to 13.2. It is made quite differently. We need some word to mark the departure, be it Leap, be it another word. I'd prefer not to suffer another name/version style change, and thus keep the word "leap" in the name.
Carlos E. R. composed on 2017-04-23 02:21 (UTC+0200):
...Because Leap is different than the previous stable versions up to 13.2. It is made quite differently. We need some word to mark the departure
Why? Previous versions are all out of support.
On 2017-04-23 02:35, Felix Miata wrote:
Carlos E. R. composed on 2017-04-23 02:21 (UTC+0200):
...Because Leap is different than the previous stable versions up to 13.2. It is made quite differently. We need some word to mark the departure
Why? Previous versions are all out of support.
Yes, but in effect it is a different series. Other name change have marked other series: SuSE, SUSE, openSUSE...
Am 23.04.2017 um 02:49 schrieb Carlos E. R.:
On 2017-04-23 02:35, Felix Miata wrote:
Carlos E. R. composed on 2017-04-23 02:21 (UTC+0200):
...Because Leap is different than the previous stable versions up to 13.2. It is made quite differently. We need some word to mark the departure
Why? Previous versions are all out of support.
Yes, but in effect it is a different series. Other name change have marked other series: SuSE, SUSE, openSUSE...
Why care? openSuSE is following it's strategy. Those who are interested can read the information on the website and/or ask questions in the forums. Everybody else.... anyway has no choice but installing the latest version of the fork he wants to. No need for an additional word. The number + website/forum that's enough.
I just think that the most simple way for everybody, where the smallest amount of people use the smallest amount of time on version numbers and names. And enabled everybody to spend a maximum amount of time on bringing things forward is: - a simple numeric version number (no exceptions, no jumping, just straight forward) - accessible information about what "politics" have been followed
That would be enough. No additional "leap" necessary
On 04/23/2017 08:00 AM, Karl Sinn wrote:
I don't even know what this means (and I don't wanna know, I just wanna keep using the latest version of the software in the most stable version possible).
Well, that's the point about Leap, you will not.
The core of the distro is at the same versions as the related SLE version, and thus /may/ not be updated in 3 or 5 years.
If you want it simpler: some packages in Leap 42.3 /may/ be the same version as in Leap 42.1.
OK, I reread the lifetime information of openSuSE. https://en.opensuse.org/Lifetime
You're right, I don't always get the absolutely newest version of a software, but therefor I get versions which are longer tested and therefor supposedly more stable than tumbleweed. Fine for me.
Still I don't need the word "leap" in the version numbering ;)
As a openSUSE Developer keeping Leap in the name is nice, because often we refer to Leap or Tumbleweed, where as without the Leap name we would be referring to tumbleweed or stable or something like that, particularly when referring to something thats across multiple leap versions.
On 2017-04-23 02:44, Simon Lees wrote:
On 04/23/2017 08:00 AM, Karl Sinn wrote:
Still I don't need the word "leap" in the version numbering ;)
As a openSUSE Developer keeping Leap in the name is nice, because often we refer to Leap or Tumbleweed, where as without the Leap name we would be referring to tumbleweed or stable or something like that, particularly when referring to something thats across multiple leap versions.
That's a much better reason than the one I said :-)
Simon Lees composed on 2017-04-23 10:44 (UTC+0930):
As a openSUSE Developer keeping Leap in the name is nice, because often we refer to Leap or Tumbleweed, where as without the Leap name we would be referring to tumbleweed or stable or something like that...
Finally a publicly expressed reason I can appreciate. :-)
Still, as an adept 10-key operator (who laments the very existence of IBM's NUM key), I can type "TW & 42.3" faster than I can "TW & Leap" even though the stroke count is identical. And, there will remain plenty of occasions to distinguish among the various iterations of Leap by their numbers. 42.3 clearly should no more be confused with TW than would Leap.
I still don't like leaping backwards from 42 to 15. It reads like something done without full consideration of potential consequences.
On 2017-04-23 03:20, Felix Miata wrote:
Still, as an adept 10-key operator (who laments the very existence of IBM's NUM key), I can type "TW & 42.3" faster than I can "TW & Leap" even though the stroke count is identical.
But TW is a name, and 42.3 is a version.
Carlos E. R. composed on 2017-04-23 03:57 (UTC+0200):
Felix Miata wrote:
Still, as an adept 10-key operator (who laments the very existence of IBM's NUM key), I can type "TW & 42.3" faster than I can "TW & Leap" even though the stroke count is identical.
But TW is a name, and 42.3 is a version.
Both are labels. Versions of TW are eight digits that change as often as daily. TW typically makes better sense as a label absent need to identify narrowly. Versions of Leap make sense to use because its breakpoints signify upstream changes accompanied by breakage that mere distro packagers may or may not be able to obviate.
Am 23.04.2017 um 03:57 schrieb Carlos E. R.:
On 2017-04-23 03:20, Felix Miata wrote:
Still, as an adept 10-key operator (who laments the very existence of IBM's NUM key), I can type "TW & 42.3" faster than I can "TW & Leap" even though the stroke count is identical.
But TW is a name, and 42.3 is a version.
Both representing different strategies. so TW on one hand (no number needed anyway) and 15 (or whatever number it'll be) is just fine.
On 2017-04-23 01:20, Felix Miata wrote:
I still don't like leaping backwards from 42 to 15. It reads like something done without full consideration of potential consequences.
Internally, in the spec files, Leap 42.x had suse_version set to 1315, because SLE12 was split off between 13.1 (having 1310) and 13.2 (having 1320) so for the software, this will be just fine and just the users be confused.
On 2017-04-23 07:54, Bernhard M. Wiedemann wrote:
On 2017-04-23 01:20, Felix Miata wrote:
I still don't like leaping backwards from 42 to 15. It reads like something done without full consideration of potential consequences.
Internally, in the spec files, Leap 42.x had suse_version set to 1315, because SLE12 was split off between 13.1 (having 1310) and 13.2 (having 1320) so for the software, this will be just fine and just the users be confused.
But not in "/etc/os-release", which is what scripts may use.
Felix Miata schrieb:
I still don't like leaping backwards from 42 to 15. It reads like something done without full consideration of potential consequences.
Dont worry, it will continue leaping back and forth to make honor of its name. Next series after 15 will be 47 - http://memory-alpha.wikia.com/wiki/47 - and then will be 23 - https://en.wikipedia.org/wiki/23_enigma - and after that, it's still open for discussion. :p
KaiRo
On 04/23/2017 08:07 AM, Robert Kaiser wrote:
Felix Miata schrieb:
I still don't like leaping backwards from 42 to 15. It reads like something done without full consideration of potential consequences.
Dont worry, it will continue leaping back and forth to make honor of its name. Next series after 15 will be 47 - http://memory-alpha.wikia.com/wiki/47 - and then will be 23 - https://en.wikipedia.org/wiki/23_enigma - and after that, it's still open for discussion. :p
I hear 3.1 will be coming up shortly. ;-)
On 04/23/2017 10:18 AM, Mathias Homann wrote:
I hear 3.1 will be coming up shortly. ;-)
can we have 3.11 for workgroups after that?
:-))
On Sunday 2017-04-23 16:18, Mathias Homann wrote:
I hear 3.1 will be coming up shortly. ;-)
can we have 3.11 for workgroups after that?
Why, there's Linux 4.11 around the corner, which is like Windows 2000 for Workgroups.
Am 23. April 2017 16:55:07 MESZ schrieb Jan Engelhardt jengelh@inai.de:
On Sunday 2017-04-23 16:18, Mathias Homann wrote:
I hear 3.1 will be coming up shortly. ;-)
can we have 3.11 for workgroups after that?
Why, there's Linux 4.11 around the corner, which is like Windows 2000 for Workgroups.
And skipping the Leap to 95? No way...
On 04/23/2017 11:11 AM, Axel Braun wrote:
Am 23. April 2017 16:55:07 MESZ schrieb Jan Engelhardt jengelh@inai.de:
On Sunday 2017-04-23 16:18, Mathias Homann wrote:
I hear 3.1 will be coming up shortly. ;-)
can we have 3.11 for workgroups after that?
Why, there's Linux 4.11 around the corner, which is like Windows 2000 for Workgroups.
And skipping the Leap to 95? No way...
Of course we can't forget ME (Moron Edition). ;)
Am 23.04.2017 um 17:11 schrieb Axel Braun:
Am 23. April 2017 16:55:07 MESZ schrieb Jan Engelhardt jengelh@inai.de:
On Sunday 2017-04-23 16:18, Mathias Homann wrote:
I hear 3.1 will be coming up shortly. ;-)
can we have 3.11 for workgroups after that?
Why, there's Linux 4.11 around the corner, which is like Windows 2000 for Workgroups.
And skipping the Leap to 95? No way...
:D
I don't even know what this means (and I don't wanna know, I just wanna keep using the latest version of the software in the most stable version possible).
Well, that's the point about Leap, you will not.
The core of the distro is at the same versions as the related SLE version, and thus /may/ not be updated in 3 or 5 years.
If you want it simpler: some packages in Leap 42.3 /may/ be the same version as in Leap 42.1.
OK, I reread the lifetime information of openSuSE. https://en.opensuse.org/Lifetime
You're right, I don't always get the absolutely newest version of a software, but therefor I get versions which are longer tested and therefor supposedly more stable than tumbleweed. Fine for me.
Still I don't need the word "leap" in the version numbering ;)
"openSUSE" -- Project which has multiple distributions. "openSUSE Leap" -- Distribution. "openSUSE Leap 42.2" -- A release of the distribution.
The same applies to Tumbleweed:
"openSUSE" -- Project which has multiple distributions. "openSUSE Tumbleweed" -- Distribution. "openSUSE Tumbleweed 20170419" -- A release of the distribution.
On 04/22/2017 01:37 PM, Richard Brown wrote:
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.
"Good plans", is it joke. and actually nothing has changed. The association between SLE-12 + 30 = Leap-42 was already ridiculous. Anyways, wasn't it clear at this time that SLE-13 would be Leap-43 and SLE-15 would be Leap-45. How can your "good" plan be bad after two years?
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.
Why is "15 + 30 = 45" more hilarious as "12 + 30 = 42"? I can't follow.
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.
We have never continued versioning. So far we re-invent stupid versions each major Leap release. I really hope that next SLE version will be 42 ... otherwise you will never learn how to make non-annoying version numbers.
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@opensuse.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@opensuse.org thread.
Regards,
Richard Brown on behalf of the openSUSE Board
On Saturday 2017-04-22 13:37, Richard Brown wrote:
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
It's a bit late for an April Fools joke.
SUSE have decided that their next version of SLE will be 15, not 13.
Nobody cares about version numbers - or any number - above 12. That is why, in many western languages, the words for numbers above 12 start to get constructed in a regular pattern. (Some Asian languages even stop bothering at 10.)
That is why RedHat, after RedHat Linux 9, did not go to 10, but started with a new name (RedHat Enterprise Linux). Of the projects which went to skyrocketing version numbers (controversial in their own right), such as firefox, systemd, ... none have dared to jump backwards. Because it'd fuck up version comparisons everywhere.
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Here is a suggestion: if SLE jumps backwards in version numbers, I'll consider it for Leap too.
On Sunday, 23 April 2017 0:51 Jan Engelhardt wrote:
Of the projects which went to skyrocketing version numbers (controversial in their own right), such as firefox, systemd, ... none have dared to jump backwards. Because it'd fuck up version comparisons everywhere.
Right. Just one thing from the top of my head:
mike@lion:~> rpm -qa --queryformat '%{VERSION}\n' | egrep '^42.[12](..*)?$' | wc -l 23
I'm pretty sure there will be others, more subtle and harder to work around (IIRC "zypper dup" is quite happy to downgrade a package if the installed version is no longer available in any active repository).
Michal Kubeček
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
BTW Wasn't there a vote about 42 being Leap's first *version* *number*? A version number *increases* over time otherwise it is no version number. We should not allow the board to ignore the fact that we want to have a version.
I expect at least 90% of openSUSE contributers would vote against decreasing/random version numbers. Would be really poor if we don't manage to stop this BS.
cu, Rudi
On 24 April 2017 at 09:35, Rüdiger Meier sweet_f_a@gmx.de wrote:
Who is actually responsible for setting up the Leap repos, Ludwig?
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness, and approved it again once we had decided it was the right course forward.
The reason the announcement was sent when it was precisely because Ludwig is increasingly keen to get the repositories ready, and he needed everyone to know why they'd be versioned the way he's going to be versioning them.
BTW Wasn't there a vote about 42 being Leap's first *version* *number*? A version number *increases* over time otherwise it is no version number. We should not allow the board to ignore the fact that we want to have a version.
The long debate giving Leaps original naming and versioning was only ended when the community used the mailing-lists to clearly and vocally request that the Board step in and decide on the projects behalf.
Given the time pressure involved (Ludwig REALLY wanted to start setting up the projects some weeks ago) the Board felt it was in the projects best interest to continue in the same vein, rather than paralyse Ludwig and our Release Team by encouraging a debate which we weren't able to reach consensus over last time.
And that is, after all, one of the reasons why we have a Board, to make decisions the Project could otherwise have a very hard time making.
Generally speaking the Board will NEVER make a decision that everyone would like - because if the Board makes a universally liked decision then there was no reason to involve the Board in the first place.
On Monday 2017-04-24 09:58, Richard Brown wrote:
On 24 April 2017 at 09:35, Rüdiger Meier sweet_f_a@gmx.de wrote:
Who is actually responsible for setting up the Leap repos, Ludwig?
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness
Well the thread should show that Ludwig should not be the _only_ technical guy to consult on this one. Still waiting on your response to that numbers should be (strictly) monotonically increasing for a particular product name.
On 24 April 2017 at 10:18, Jan Engelhardt jengelh@inai.de wrote:
On Monday 2017-04-24 09:58, Richard Brown wrote:
On 24 April 2017 at 09:35, Rüdiger Meier sweet_f_a@gmx.de wrote:
Who is actually responsible for setting up the Leap repos, Ludwig?
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness
Well the thread should show that Ludwig should not be the _only_ technical guy to consult on this one. Still waiting on your response to that numbers should be (strictly) monotonically increasing for a particular product name.
Ludwig was not the _only_ technical guide consulted, but obviously the most important one given that Leap is _his_ distribution to release.
If you're referring to yourself as a "technical guy", I do not see any email from you asking any questions, nor making statements which would imply we should have consulted with you.
The one email I think you might be referring to you said you were losing faith in the board, followed by saying "Nobody cares about version numbers", followed by the suggestion "if SLE jumps backwards in version numbers, I'll consider it for Leap too."
These are things the Board already considered, so I'm afraid to say you are not bringing anything new to the table.
Given the plan for Leap 15 from now on will be to make the most of this version sync and stick with matching SLE versions for the indefinite future I took your statement as mostly agreeing with the direction of travel, and your hurtful comment about the board as a frustration about how we got there, which I sympathise with but I certainly had no intention of addressing publicly.
On Monday 2017-04-24 10:30, Richard Brown wrote:
On 24 April 2017 at 10:18, Jan Engelhardt jengelh@inai.de wrote:
On Monday 2017-04-24 09:58, Richard Brown wrote:
On 24 April 2017 at 09:35, Rüdiger Meier sweet_f_a@gmx.de wrote:
Who is actually responsible for setting up the Leap repos, Ludwig?
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness
Well the thread should show that Ludwig should not be the _only_ technical guy to consult on this one. Still waiting on your response to that numbers should be (strictly) monotonically increasing for a particular product name.
Ludwig was not the _only_ technical guide consulted, but obviously the most important one given that Leap is _his_ distribution to release.
If you're referring to yourself as a "technical guy", I do not see any email from you asking any questions, nor making statements which would imply we should have consulted with you.
You made a board-internal decision (that's ok) You conveyed this as an announcement rather than a proposal You "made facts", as we say User reception: They've already made up their mind
I am saying you handled this one *really really badly*.
The process for the openSUSE's distribution name (Oak/Leap/..) went a lot better, and that even was just a preference thing where one never really outweighs any other.
The number monotony as a technical argument carries a bigger weight. Which means now that it has been brought forward (by others as well) you ought not to ignore it any longer. Considering but ultimately rejecting it is also going to be a hard sell.
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok? Just the amount of negative PR coming out of all this should have prevented the board from ever making such a precast decision, but I guess there is no "don't destruct the project" clauses in the board's rules, are there?
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
On 04/24/2017 11:07 AM, Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Yeah but what Jan is talking about here is jumping *backwards*. 12->15 still maintains the common sense that newer version should be higher than the previous one. However 42->15 does not.
Just image new users who want to try openSUSE for the first time. They will obviously go and install Leap 42 because they naturally assume that openSUSE 42 is newer than openSUSE 15
On 04/24/2017 12:07 PM, Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
No, I guess they simply wanted to avoid the "unlucky 13" and 14 because of the tetraphobia of Asian customers. There are several other projects which jumped from 12 to 15 in past for this reason.
Jumping backwards is something very special of openSUSE Leap. I guess it's hard to find another project who did the same. Maybe some projects exist with versions which are aligned to 2-digit year numbers but I'm sure most of them would provide a sane machine-readable ordered version, different from the random marketing version.
cu, Rudi
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal Kubeček
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal Kubeček
Sounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
Jumping backwards is so bad that simply defeats the purpose of versioning. If version numbers do not matter to us, we simply need to stop using them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2017-04-24 23:26, Markos Chandras wrote:
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
Yes, I concur. But I'm nobody ;-)
- -- Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" (Minas Tirith))
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal KubečekSounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
On 04/24/2017 11:14 PM, Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal KubečekSounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Well, yes, but then you need to explain over and over why 15 is newer than 42 and why this was considered to be a good decision.. And while it's somewhat easy to explain all that in this list, openSUSE is also being discussed in so many other places so you can't really contain it and prevent people from making the wrong assumptions about this decision.
However, if you rename the whole thing then people will disassociate Leap/42 with Foobar/15 so no questions will be asked (at least not as many as we are asking right now)
On 25 April 2017 at 00:29, Markos Chandras mchandras@suse.de wrote:
On 04/24/2017 11:14 PM, Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal KubečekSounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Well, yes, but then you need to explain over and over why 15 is newer than 42 and why this was considered to be a good decision.. And while it's somewhat easy to explain all that in this list, openSUSE is also being discussed in so many other places so you can't really contain it and prevent people from making the wrong assumptions about this decision.
However, if you rename the whole thing then people will disassociate Leap/42 with Foobar/15 so no questions will be asked (at least not as many as we are asking right now)
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
But at the same time, I don't intend to live with that. We learned lessons from 42.x's numbering. We never made a clear announcement as to why, we only announced what we were doing,
This time, the opening mail to this thread contained a clear, verbose, end to end justification, explaining the history, the other options considered, and the reasoning that was most prominent in the Boards minds when choosing 15.
Unlike last time, this announcement was sent clearly and prominently, which has been noted by several media outlets. LWN, Phoronix, Golem for example have all done a fair job of both summarising the decision, its reasons, but also linked or quoted to the mail in full.
While obviously no decision like this is universally welcomed, the tone of the comments on those various news outlets includes a frequency and volume of positivity which may not be reflected on this list but does give me considerable hope that we are doing a very good job of spreading this message well and that the "Leap is close to SLE" message is offsetting any disruption from the "openSUSE did what with their versions again?" message.
This thread of positivity regarding the change has also been reflected in various social media platforms, such as our Forums, Facebook, Twitter, Google+ and Reddit. This is something I do not remember from the 42.x change - I would describe the mood back then as one of considerably more confusion than 15 is causing now.
So all things considered, I'm not that displeased with how Leap 15 is being accepted by the big wide world so far. I think we're doing a better job of getting the message out in a digestable way than the last time we did this, and I think it helps that Leap 15 is just a whole lot more boring than 42. And boring is good for Leap, I don't mind if this is the last time it ever gets in the news for any reason besides the solid, moderately paced incremental update of its software and its features within.
-- markos
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, 25 April 2017 0:47 Richard Brown wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
You still do not understand the fundamental difference between skipping from 13 to 42 and skipping from 42 to 15, do you? Skipping _forward_ is just common crazy, people will just roll their eyes and call you names for some time and life will go on; Skipping _back_ is utterly wrong in principle, it beats the one basic property of version numbers that everyone (OK, almost everyone, apparently) expects from them. And it's going to break things.
Michal Kubeček
On 25 April 2017 at 07:26, Michal Kubecek mkubecek@suse.cz wrote:
On Tuesday, 25 April 2017 0:47 Richard Brown wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
You still do not understand the fundamental difference between skipping from 13 to 42 and skipping from 42 to 15, do you? Skipping _forward_ is just common crazy, people will just roll their eyes and call you names for some time and life will go on; Skipping _back_ is utterly wrong in principle, it beats the one basic property of version numbers that everyone (OK, almost everyone, apparently) expects from them. And it's going to break things.
Michal Kubeček
Moving from suse_version 1315 to suse_version 1500 is going to break things less than when we went from suse_version 1320 in 13.2 to 1315 in Leap 42.1
Sure there are version comparisons elsewhere, especially configuration management like saltstack, puppet, etc. There will be some cost of the decision to go from Leap 42.1 and Leap 15 there. But in all cases with people I've spoken with so far, this has been defined as a onetime cost, not critical, and mostly involves removing or simplifying the nasty hacks they had to out in place for 42.1 in the first place, so it's not terrible.
And given Leap 15 is like a year away, unlike when we decided Leap 42.1's version number barely weeks before the release, this time people have plenty of warning to prepare.
On Tue, Apr 25, 2017 at 08:19:23AM +0200, Richard Brown wrote:
Moving from suse_version 1315 to suse_version 1500 is going to break things less than when we went from suse_version 1320 in 13.2 to 1315 in Leap 42.1
Sure there are version comparisons elsewhere, especially configuration management like saltstack, puppet, etc. There will be some cost of the decision to go from Leap 42.1 and Leap 15 there. But in all cases with people I've spoken with so far, this has been defined as a onetime cost, not critical, and mostly involves removing or simplifying the nasty hacks they had to out in place for 42.1 in the first place, so it's not terrible.
And given Leap 15 is like a year away, unlike when we decided Leap 42.1's version number barely weeks before the release, this time people have plenty of warning to prepare.
As a heavy user and contributor (of openSUSE/SLES conditionals) on both the abovementioned configuration management systems, I totally agree with every single word of Richard's mail here. As a packager I have the same feelings regarding the upcoming macro udpates, so I fully support this move. Yes it's going to be some cleanup work on my side initially, but i's one time work and I am looking forward on doing it
On Tue, Apr 25, 2017 at 12:47 AM, Richard Brown RBrownCCB@opensuse.org wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
But at that time the version number still incremented. This is not at all the same thing here. How many SPECs in OBS have a test that the version number is <> some number? I see them all the time. I can just imagine the mess when all these get built expecting to find features added in 42.x. Or, even more difficult, features added in 15.
Isn't one reason a version number is, well, a NUMBER, and not a version phrase, is so that it can be used in these comparisons? And isn't the assumption that a bigger number is assigned to a release that precedes one with a smaller number? Given how prevalent these comparisons are in SPEC files, I think it is safe to say that it is a common assumption.
On Tue, Apr 25, 2017 at 7:34 AM, Roger Oberholtzer roger.oberholtzer@gmail.com wrote:
Isn't one reason a version number is, well, a NUMBER, and not a version phrase, is so that it can be used in these comparisons? And isn't the assumption that a bigger number is assigned to a release that precedes one with a smaller number? Given how prevalent these comparisons are in SPEC files, I think it is safe to say that it is a common assumption.
Sigh. I typed wrong:
And isn't the assumption that a bigger number is assigned to a release that *follows* one with a smaller number? Given how prevalent these comparisons are in SPEC files, I think it is safe to say that it is a common assumption.
On 25 April 2017 at 07:34, Roger Oberholtzer roger.oberholtzer@gmail.com wrote:
On Tue, Apr 25, 2017 at 12:47 AM, Richard Brown RBrownCCB@opensuse.org wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
But at that time the version number still incremented. This is not at all the same thing here. How many SPECs in OBS have a test that the version number is <> some number? I see them all the time. I can just imagine the mess when all these get built expecting to find features added in 42.x. Or, even more difficult, features added in 15.
Isn't one reason a version number is, well, a NUMBER, and not a version phrase, is so that it can be used in these comparisons? And isn't the assumption that a bigger number is assigned to a release that precedes one with a smaller number? Given how prevalent these comparisons are in SPEC files, I think it is safe to say that it is a common assumption.
You seem to have neglected the part of my email where I discussed this or you're not as involved in packaging for Leap to realise that the problem you describe is a bigger issue for 42.x than it will be for 15
There are currently 3 different references for spec files to use when doing version comparisons in our distros
sle_version - the "precise version" macro for SLE - it used for when SLE packages need to distinguish a specific version of SLE. It's used relatively rarely. It is currently at 120200 for SLE 12 SP1.
leap_version - the precise version macro for Leap. It was created because people needed a simple clear reference to the Leap version because it isn't necessarily intuitive which sle_version is which Leap version. It's currently 420200 for 42.2. For 42.1 it doesn't exist so you have to use sle_version anyway.
suse_version - the "major version" macro. It is the most prevelently used reference of version number in our distribution, It arguably matters more than any number any user sees.
This is currently 1315 for SLE 12 and Leap 42. It is 1330 for Tumbleweed. It was 1320 for openSUSE 13.2
Let me just highlight that for a second. Leap 42.x has a lower suse_version number than 13.2 had. With Leap 42.x we went "backwards" in version numbers in a way far more substantive than what we are talking about here. That was 2 years ago. openSUSE did not sponantiously combust. The world did not end. Any issues this jump back caused, we fixed, and Leap turned into the successful beast we love today.
For Leap 15 and SLE 15 the suse_version will be 1500
It will go forward, those spec file references will resolve nicely, this version decision will be far less technically painful for our packagers than 42.1 was, and as we have already estabshed 42.1 wasn't that painful.
In fact a far bigger problem will be the impact on Tumbleweed because there are far too many references to suse_version==1330 that are going to explode when Tumbleweed moves beyond 1500, which it will have to regardless of what we do with Leaps version.
The decision to go to Leap 15 also means we can deprecate and eventually remove the leap_version macro, because it will be unnecessary now sle_version will match for Leap and SLE. In the meantime, we might even increment the leap_version to something like 450000 to keep things smooth and resolving in the meanwhile.
In short
On the rpm versioning side of things everything is increasing, nothing is going backwards, we're making things simpler for our packagers, and even if things were going backwards we've done it before and the world did not end.
On Tue, Apr 25, 2017 at 7:58 AM, Richard Brown RBrownCCB@opensuse.org wrote:
On the rpm versioning side of things everything is increasing, nothing is going backwards, we're making things simpler for our packagers, and even if things were going backwards we've done it before and the world did not end.
Thanks for the clarification. I seem to have gotten that wrong. So, from an OBS POV all should be okay. That is a good thing.
How about the numbers reported in /etc/os-release? Those are 42.x, and will go backwards. I suspect many Makefiles use this information to make decisions. I know ours do.
On 04/25/2017 07:58 AM, Richard Brown wrote:
On 25 April 2017 at 07:34, Roger Oberholtzer roger.oberholtzer@gmail.com wrote:
On Tue, Apr 25, 2017 at 12:47 AM, Richard Brown RBrownCCB@opensuse.org wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
But at that time the version number still incremented. This is not at all the same thing here. How many SPECs in OBS have a test that the version number is <> some number? I see them all the time. I can just imagine the mess when all these get built expecting to find features added in 42.x. Or, even more difficult, features added in 15.
Isn't one reason a version number is, well, a NUMBER, and not a version phrase, is so that it can be used in these comparisons? And isn't the assumption that a bigger number is assigned to a release that precedes one with a smaller number? Given how prevalent these comparisons are in SPEC files, I think it is safe to say that it is a common assumption.
You seem to have neglected the part of my email where I discussed this or you're not as involved in packaging for Leap to realise that the problem you describe is a bigger issue for 42.x than it will be for 15
There are currently 3 different references for spec files to use when doing version comparisons in our distros
sle_version - the "precise version" macro for SLE - it used for when SLE packages need to distinguish a specific version of SLE. It's used relatively rarely. It is currently at 120200 for SLE 12 SP1.
leap_version - the precise version macro for Leap. It was created because people needed a simple clear reference to the Leap version because it isn't necessarily intuitive which sle_version is which Leap version. It's currently 420200 for 42.2. For 42.1 it doesn't exist so you have to use sle_version anyway.
suse_version - the "major version" macro. It is the most prevelently used reference of version number in our distribution, It arguably matters more than any number any user sees.
This is currently 1315 for SLE 12 and Leap 42. It is 1330 for Tumbleweed. It was 1320 for openSUSE 13.2
Let me just highlight that for a second. Leap 42.x has a lower suse_version number than 13.2 had. With Leap 42.x we went "backwards" in version numbers in a way far more substantive than what we are talking about here.
That was 2 years ago. openSUSE did not sponantiously combust. The world did not end. Any issues this jump back caused, we fixed, and Leap turned into the successful beast we love today.
For Leap 15 and SLE 15 the suse_version will be 1500
It will go forward, those spec file references will resolve nicely, this version decision will be far less technically painful for our packagers than 42.1 was, and as we have already estabshed 42.1 wasn't that painful.
In fact a far bigger problem will be the impact on Tumbleweed because there are far too many references to suse_version==1330 that are going
to explode when Tumbleweed moves beyond 1500, which it will have to regardless of what we do with Leaps version.
The decision to go to Leap 15 also means we can deprecate and eventually remove the leap_version macro, because it will be unnecessary now sle_version will match for Leap and SLE. In the meantime, we might even increment the leap_version to something like 450000 to keep things smooth and resolving in the meanwhile.
In short
On the rpm versioning side of things everything is increasing, nothing is going backwards, we're making things simpler for our packagers, and even if things were going backwards we've done it before and the world did not end.
In short, you have no idea what you are doing.
Compare this with our RHEL, CentOS and Fedora repos on OBS. Here we have independent macros centos_version, rhel_version and fedora_version. That's simple, obviously translatable from and to /etc/os-release, never saw discussions or questions about it. What we have for the suse flavors is just a big mess.
Actually the whole versioning thing is an absolute simple no-brainer. It's not easy to do it wrong, but you do.
cu, Rudi
On Monday, 24 April 2017 23:47:03 BST Richard Brown wrote:
On 25 April 2017 at 00:29, Markos Chandras mchandras@suse.de wrote:
On 04/24/2017 11:14 PM, Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote: > In a real company/product (like SLE), there would be a PR and sales > department preventing from jumping backwards surely. Just because > openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal KubečekSounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Well, yes, but then you need to explain over and over why 15 is newer than 42 and why this was considered to be a good decision.. And while it's somewhat easy to explain all that in this list, openSUSE is also being discussed in so many other places so you can't really contain it and prevent people from making the wrong assumptions about this decision.
However, if you rename the whole thing then people will disassociate Leap/42 with Foobar/15 so no questions will be asked (at least not as many as we are asking right now)
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x (yes, drop Leap) to keep it inline with SLE going forward. I'm sure that will placate and seem sensible most people
But at the same time, I don't intend to live with that. We learned lessons from 42.x's numbering. We never made a clear announcement as to why, we only announced what we were doing,
This time, the opening mail to this thread contained a clear, verbose, end to end justification, explaining the history, the other options considered, and the reasoning that was most prominent in the Boards minds when choosing 15.
Unlike last time, this announcement was sent clearly and prominently, which has been noted by several media outlets. LWN, Phoronix, Golem for example have all done a fair job of both summarising the decision, its reasons, but also linked or quoted to the mail in full.
While obviously no decision like this is universally welcomed, the tone of the comments on those various news outlets includes a frequency and volume of positivity which may not be reflected on this list but does give me considerable hope that we are doing a very good job of spreading this message well and that the "Leap is close to SLE" message is offsetting any disruption from the "openSUSE did what with their versions again?" message.
This thread of positivity regarding the change has also been reflected in various social media platforms, such as our Forums, Facebook, Twitter, Google+ and Reddit. This is something I do not remember from the 42.x change - I would describe the mood back then as one of considerably more confusion than 15 is causing now.
So all things considered, I'm not that displeased with how Leap 15 is being accepted by the big wide world so far. I think we're doing a better job of getting the message out in a digestable way than the last time we did this, and I think it helps that Leap 15 is just a whole lot more boring than 42. And boring is good for Leap, I don't mind if this is the last time it ever gets in the news for any reason besides the solid, moderately paced incremental update of its software and its features within.
-- markos
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x (yes, drop Leap) to keep it inline with SLE going forward. I'm sure that will placate and seem sensible most people
+1
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time?
It's a manager thing. Never admit to a mistake when you can spend hours trying to come up with a way to make it look like A Good Idea instead. for reference, see The Internet Of Things.
It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x (yes, drop Leap) to keep it inline with SLE going forward. I'm sure that will placate and seem sensible most people
+1. repeatedly.
Cheers Mathias
On 25/04/17 20:34, ianseeks wrote:
.........................
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x (yes, drop Leap) to keep it inline with SLE going forward. I'm sure that will placate and seem sensible most people
Abso-bloody-lutely!
On Tuesday 2017-04-25 10:34, ianseeks wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x
Is going backwards, and the discussion that it entails, a good use of time? It would be easier to swallow the pride and admit that REPEATING a jump is even worse.
On 25 April 2017 at 11:37, Jan Engelhardt jengelh@inai.de wrote:
On Tuesday 2017-04-25 10:34, ianseeks wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x
Is going backwards, and the discussion that it entails, a good use of time? It would be easier to swallow the pride and admit that REPEATING a jump is even worse.
Come on Jan, you're not doing your public perception any favours here. As a key member of the Factory review team you're expected to be rational and considerate. You wouldn't like it if I publicly complained in terms of "good use of time" every time you get on your high horse and block other contributors contributions for reasons which you think are right, would you?
I'd advise you take a step back and consider that your own personal brand is an important thing to keep in good order. The Board can take its responsibility/praise for whatever harm/benefit this decision may have done to the openSUSE brand.
There is no 'pride' to swallow here. This was a collective decision of the openSUSE Board, the body elected by the community with the responsibility to make decisions on behalf of the community. We did our job, to the best of our ability, considering all of the factors we could. There are no new factors that we didn't consider that have been raised in this thread, so there is no grounds for reconsidering the decision.
And besides, lets imagine we DID reconsider - at this point we'd cause even more confusion and disruption given the world already knows that the next version is going to be Leap 15. Yeah, no, it would take a pretty compelling new piece of information to justify that cost now.
And as you're a Factory reviewer, also consider it from a packagers perspective
"suse_version for Leap 45 is changing from 1315 to 1500. What's the relationship between suse_version and the distro you're using? No clue. You just need to learn. You're new? f*ck you, good luck becoming an openSUSE packagers. You need to reference a specific minor version? the sle_version is changing from 120300 to 150000, the leap_version is changing from 420300 to 450000, but not if you're still building packages for Leap 42.1 that is still using sle_version 120100. You want to build for Tumbleweed, SLE, and Leap? haha, good luck."
The death of the rpm leap_version macro and the simplified nature of suse_version actually having some link to reality now should make things easier for our packagers.
"suse_version for Leap 15 and SLE 15 is 1500. They'll increment together from now on. sle_version includes the minor version for when you need to be precise, like 150100. We're making it as easy as possible to build for Tumbleweed, SLE, and Leap while still ensuring all 3 can diverge when they need to."
Which should mean you should have an easier time and less messed up nested if nonsense in spec files.
The whole 'backwards' complaint is nonsense given we did it with Leap already, in a far more technically invasive way.
We need to find the best way forward for the long term ease of maintainability, clarity for new contributors, and simple easy messaging for the big wide world about the unique things about Leap that differentiate it from every other distribution out there.
Leap 15 ticks all of those boxes. It's the right choice, and I'll probably keep thinking this way until someone actually provides substantive, practical, hands-on evidence of something which the Board overlooked in our decision.
Regards
Richard Brown píše v Út 25. 04. 2017 v 12:01 +0200:
On 25 April 2017 at 11:37, Jan Engelhardt jengelh@inai.de wrote:
On Tuesday 2017-04-25 10:34, ianseeks wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x
Is going backwards, and the discussion that it entails, a good use of time? It would be easier to swallow the pride and admit that REPEATING a jump is even worse.
Come on Jan, you're not doing your public perception any favours here. As a key member of the Factory review team you're expected to be rational and considerate. You wouldn't like it if I publicly complained in terms of "good use of time" every time you get on your high horse and block other contributors contributions for reasons which you think are right, would you?
I'd advise you take a step back and consider that your own personal brand is an important thing to keep in good order. The Board can take its responsibility/praise for whatever harm/benefit this decision may have done to the openSUSE brand.
There is no 'pride' to swallow here. This was a collective decision of the openSUSE Board, the body elected by the community with the responsibility to make decisions on behalf of the community. We did our job, to the best of our ability, considering all of the factors we could. There are no new factors that we didn't consider that have been raised in this thread, so there is no grounds for reconsidering the decision.
And besides, lets imagine we DID reconsider - at this point we'd cause even more confusion and disruption given the world already knows that the next version is going to be Leap 15. Yeah, no, it would take a pretty compelling new piece of information to justify that cost now.
And as you're a Factory reviewer, also consider it from a packagers perspective
"suse_version for Leap 45 is changing from 1315 to 1500. What's the relationship between suse_version and the distro you're using? No clue. You just need to learn. You're new? f*ck you, good luck becoming an openSUSE packagers. You need to reference a specific minor version? the sle_version is changing from 120300 to 150000, the leap_version is changing from 420300 to 450000, but not if you're still building packages for Leap 42.1 that is still using sle_version 120100. You want to build for Tumbleweed, SLE, and Leap? haha, good luck."
The death of the rpm leap_version macro and the simplified nature of suse_version actually having some link to reality now should make things easier for our packagers.
"suse_version for Leap 15 and SLE 15 is 1500. They'll increment together from now on. sle_version includes the minor version for when you need to be precise, like 150100. We're making it as easy as possible to build for Tumbleweed, SLE, and Leap while still ensuring all 3 can diverge when they need to."
Which should mean you should have an easier time and less messed up nested if nonsense in spec files.
The whole 'backwards' complaint is nonsense given we did it with Leap already, in a far more technically invasive way.
We need to find the best way forward for the long term ease of maintainability, clarity for new contributors, and simple easy messaging for the big wide world about the unique things about Leap that differentiate it from every other distribution out there.
Leap 15 ticks all of those boxes. It's the right choice, and I'll probably keep thinking this way until someone actually provides substantive, practical, hands-on evidence of something which the Board overlooked in our decision.
I really have to back up Richard here.
We "as a board" considered all the options and actually going back to match with SUSE Linux Enterprise products seem like the best choice.
In tooling we will be matched up as per what Richard wrote, so packagers won't have to remember that leap is 1315 and defined macro is_opensuse and minor version is yet another macro.
From the simple perspective indeed 15 < 42 :) But on the other hand if it lets us to clean up rest of the mess it is worth doing bit of hassle. Esp. from my packagers point of view I have to say this is quite improving the situation with the macros.
Cheers
Tom
On 04/25/2017 01:23 PM, Tomas Chvatal wrote:
Richard Brown píše v Út 25. 04. 2017 v 12:01 +0200:
On 25 April 2017 at 11:37, Jan Engelhardt jengelh@inai.de wrote:
On Tuesday 2017-04-25 10:34, ianseeks wrote:
I remember people saying the same when we jumped to 42.x just over two years ago.
In many ways, they were wrong - I didn't spend as much time as I expected repeating that message. It's been over a year since I had to deal with a question on the topic. One year of having to answer questions about why 15? Sure, I can live with that.
Is spending man hours for a year trying to justify a mistake with firstly with Leap 42 and now going backwards a good use of time? It would be easier to swallow the old pride and say, ok, we got it wrong with Leap 42, lets just call it opensuse 15.x
Is going backwards, and the discussion that it entails, a good use of time? It would be easier to swallow the pride and admit that REPEATING a jump is even worse.
Come on Jan, you're not doing your public perception any favours here. As a key member of the Factory review team you're expected to be rational and considerate. You wouldn't like it if I publicly complained in terms of "good use of time" every time you get on your high horse and block other contributors contributions for reasons which you think are right, would you?
I'd advise you take a step back and consider that your own personal brand is an important thing to keep in good order. The Board can take its responsibility/praise for whatever harm/benefit this decision may have done to the openSUSE brand.
There is no 'pride' to swallow here. This was a collective decision of the openSUSE Board, the body elected by the community with the responsibility to make decisions on behalf of the community. We did our job, to the best of our ability, considering all of the factors we could. There are no new factors that we didn't consider that have been raised in this thread, so there is no grounds for reconsidering the decision.
And besides, lets imagine we DID reconsider - at this point we'd cause even more confusion and disruption given the world already knows that the next version is going to be Leap 15. Yeah, no, it would take a pretty compelling new piece of information to justify that cost now.
And as you're a Factory reviewer, also consider it from a packagers perspective
"suse_version for Leap 45 is changing from 1315 to 1500. What's the relationship between suse_version and the distro you're using? No clue. You just need to learn. You're new? f*ck you, good luck becoming an openSUSE packagers. You need to reference a specific minor version? the sle_version is changing from 120300 to 150000, the leap_version is changing from 420300 to 450000, but not if you're still building packages for Leap 42.1 that is still using sle_version 120100. You want to build for Tumbleweed, SLE, and Leap? haha, good luck."
The death of the rpm leap_version macro and the simplified nature of suse_version actually having some link to reality now should make things easier for our packagers.
"suse_version for Leap 15 and SLE 15 is 1500. They'll increment together from now on. sle_version includes the minor version for when you need to be precise, like 150100. We're making it as easy as possible to build for Tumbleweed, SLE, and Leap while still ensuring all 3 can diverge when they need to."
Which should mean you should have an easier time and less messed up nested if nonsense in spec files.
The whole 'backwards' complaint is nonsense given we did it with Leap already, in a far more technically invasive way.
We need to find the best way forward for the long term ease of maintainability, clarity for new contributors, and simple easy messaging for the big wide world about the unique things about Leap that differentiate it from every other distribution out there.
Leap 15 ticks all of those boxes. It's the right choice, and I'll probably keep thinking this way until someone actually provides substantive, practical, hands-on evidence of something which the Board overlooked in our decision.
I really have to back up Richard here.
We "as a board" considered all the options and actually going back to match with SUSE Linux Enterprise products seem like the best choice.
In tooling we will be matched up as per what Richard wrote, so packagers won't have to remember that leap is 1315 and defined macro is_opensuse and minor version is yet another macro.
Of course I have to remember it because I will surely build my Leap packages at least 6 more years.
From the simple perspective indeed 15 < 42 :)
Decrementing the version was the only thing you could do wrong, and you did it. Thanks, I'll get over it. But please stop trying to justify this. Nobody decrements version numbers. Show me one other project which did the same BS. Don't you get that you did something wrong?
But on the other hand if it lets us to clean up rest of the mess it is worth doing bit of hassle. Esp. from my packagers point of view I have to say this is quite improving the situation with the macros.
I wish you that all the upstream sources you are packaging would decrement their version.
cu, Rudi
On 25.04.2017 13:50, Rüdiger Meier wrote:
But on the other hand if it lets us to clean up rest of the mess it is worth doing bit of hassle. Esp. from my packagers point of view I have to say this is quite improving the situation with the macros.
I wish you that all the upstream sources you are packaging would decrement their version.
That's why zypper dup ignores version numbers actually - or rpm supports epoche - upstream sources *do it all the time*. Most of the time because they see numbers differently than rpm does, but it's a bigger problem in daily distribution development than you seem to think.
Greetings, Stephan
On 04/25/2017 02:08 PM, Stephan Kulow wrote:
On 25.04.2017 13:50, Rüdiger Meier wrote:
But on the other hand if it lets us to clean up rest of the mess it is worth doing bit of hassle. Esp. from my packagers point of view I have to say this is quite improving the situation with the macros.
I wish you that all the upstream sources you are packaging would decrement their version.
That's why zypper dup ignores version numbers actually
Nice that "zypper dup" can handle package downgrades. It would still write out messages to the user that he is about to *downgrade*" certain packages.
- or rpm supports
epoche - upstream sources *do it all the time*. Most of the time because they see numbers differently than rpm does, but it's a bigger problem in daily distribution development than you seem to think.
In my daily life I have to use --force* flags for "zypper up" or "rpm -U" to install packages with smaller version numbers.
Decrementing version numbers are still non-sense.
cu. Rudi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/25/2017 01:23 PM, Tomas Chvatal wrote:
We "as a board" [...]
Wow - this thread has up to 157 messages now. I'm really curious whether we'll also get that many responses when it once will come to the question who wants to join the board and spend her/his spare time to do the job ...
For me this discussion is like bikeshedding ... and I'm starting to like 15. ;-)
Have a nice day, Berny
On Tuesday, 25 April 2017 15:45 Bernhard Voelker wrote:
I'm really curious whether we'll also get that many responses when it once will come to the question who wants to join the board and spend her/his spare time to do the job ...
Joining the board would require becoming a member. The level of my disagreement with openSUSE leadership and their approach is too high to seriously consider applying for membership. (If I were a member, I would most likely have resigned already.)
I'm afraid all I could hope for in the board would be more frustration and I'm probably too old for such futile effort. There are other ways to spend my time where I can be actually useful.
Michal Kubeček
Hello,
On Apr 25 15:45 Bernhard Voelker wrote (excerpt):
For me this discussion is like bikeshedding
exactly!
And the crucial point about bikeshedding discussions is that they are a natural human habit.
I recommend to actually read Northcote Parkinson's book to get a better understanding about such kind of things.
Whatever kind of "management / board / big-boss / emperor" may try to avoid bikeshedding discussions by making "well founded final decisions" but that fails in practice.
The reason behind is that everybody can have a valid opinion about bikeshedding issues so that everybody can discuss bikeshedding topics while in contrast for complex issues only a few experts have a valid opinion and others may prefer to keep silent over the risk to make themselves look like idiots if they publish their "silly" opinion and when they have an opinion they may prefer to tell it only privately which results another interesting effect: rumors.
In the end what I like to say is that one cannot work against natural human habits:
If there is a bikeshedding issue, there must be a fair way to discuss it.
Kind Regards Johannes Meixner
On 25.04.2017 12:01, Richard Brown wrote:
It's the right choice, and I'll probably keep thinking this way until someone actually provides substantive, practical, hands-on evidence of something which the Board overlooked in our decision.
The users.
To paraphrase A'rpi (of MPlayer fame): "My software runs just fine without users"
Not sure that's the direction we are wanting to go.
On Tuesday 2017-04-25 12:01, Richard Brown wrote:
Is going backwards, and the discussion that it entails, a good use of time? It would be easier to swallow the pride and admit that REPEATING a jump is even worse.
You wouldn't like it if I publicly complained in terms of "good use of time" every time you get on your high horse and block other contributors contributions for reasons which you think are right, would you?
I do not mind anyone complaining, especially since you probably have the higher horse of us two.
And besides, lets imagine we DID reconsider - at this point we'd cause even more confusion and disruption given the world already knows that the next version is going to be Leap 15.
First Strikes usually have that kind of effect that you don't want a second one either way. Well played.
And as you're a Factory reviewer, also consider it from a packagers perspective
Yesyes, you posted a solution to the %macro problems, but I am still keen on hearing your nondestructive solution for /etc/os-release's VERSION_ID, if there is any.
On 25.04.2017 13:29, Jan Engelhardt wrote:
Yesyes, you posted a solution to the %macro problems, but I am still keen on hearing your nondestructive solution for /etc/os-release's VERSION_ID, if there is any.
While I understand you insist on increasing version numbers, I don't really see too many technical arguments for it actually.
Because most real life cases I can think of won't be able to use a reliable > no matter how often openSUSE screws version numbers anyway. Because you just don't know any details about future versions.
I.e. normally you support X versions/platforms and form your conditionals based on that. So a >= 1500 && < 4200 will bring you a while.
Especially as Tumbleweed has 20170417 in there, you will need some extra logic anyway to support openSUSE releases in a broader sense.
Greetings, Stephan
On Tuesday 2017-04-25 13:40, Stephan Kulow wrote:
On 25.04.2017 13:29, Jan Engelhardt wrote:
Yesyes, you posted a solution to the %macro problems, but I am still keen on hearing your nondestructive solution for /etc/os-release's VERSION_ID, if there is any.
While I understand you insist on increasing version numbers, I don't really see too many technical arguments for it actually.
Because most real life cases I can think of won't be able to use a reliable > no matter how often openSUSE screws version numbers anyway. Because you just don't know any details about future versions.
It's not about future versions but past ones:
if (v < 1200) dit; else if (v < 1300) dat; else if (v < 4200) dot; else { current practice, hope that it will work for enough future versions until the next script revision is out }
Should they have written ">= x00 && <= xx99" instead? Maybe. Either way, they could have not know that 1500 would come along.
I.e. normally you support X versions/platforms and form your conditionals based on that. So a >= 1500 && < 4200 will bring you a while.
Especially as Tumbleweed has 20170417 in there, you will need some extra logic anyway to support openSUSE releases in a broader sense.
case "$NAME" in "openSUSE Leap") if (v < 4200 ) echo "Your glibc is too old" "openSUSE Tumbleweed") if (v < 20170000) echo "Your zen is too old" esac
On 25.04.2017 13:54, Jan Engelhardt wrote:
On Tuesday 2017-04-25 13:40, Stephan Kulow wrote:
On 25.04.2017 13:29, Jan Engelhardt wrote:
Yesyes, you posted a solution to the %macro problems, but I am still keen on hearing your nondestructive solution for /etc/os-release's VERSION_ID, if there is any.
While I understand you insist on increasing version numbers, I don't really see too many technical arguments for it actually.
Because most real life cases I can think of won't be able to use a reliable > no matter how often openSUSE screws version numbers anyway. Because you just don't know any details about future versions.
It's not about future versions but past ones:
if (v < 1200) dit; else if (v < 1300) dat; else if (v < 4200) dot; else { current practice, hope that it will work for enough future versions until the next script revision is out }
Should they have written ">= x00 && <= xx99" instead? Maybe. Either way, they could have not know that 1500 would come along.
Right - but such as life in the dungeon called open source. Many upstreams have funny ideas as well - not just about version numbers.
But as Richard said, telling the world now that openSUSE is crazy and that the release next year will be completely off the version scheme should give enough time for people adopting to 42.3 to consider 15 as they write their conditions and receipes.
Greetings, Stephan
Am 2017-04-25 00:29, schrieb Markos Chandras:
On 04/24/2017 11:14 PM, Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
MichalKubeček
Sounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Well, yes, but then you need to explain over and over why 15 is newer than 42 and why this was considered to be a good decision.. And while it's somewhat easy to explain all that in this list, openSUSE is also being discussed in so many other places so you can't really contain it and prevent people from making the wrong assumptions about this decision.
However, if you rename the whole thing then people will disassociate Leap/42 with Foobar/15 so no questions will be asked (at least not as many as we are asking right now)
I think also peaople saying the same.
For me, when it should be unconditional 15.x, the best is openSUSE Leap 15.x
Because it gives SLE, Tumbleweed and Leap. You can easily differnt between this "versions". It's very clearly and easy.
On Tuesday, 25 April 2017 07:19:56 BST Eric Schirra wrote:
Am 2017-04-25 00:29, schrieb Markos Chandras:
On 04/24/2017 11:14 PM, Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote: > In a real company/product (like SLE), there would be a PR and > sales > department preventing from jumping backwards surely. Just because > openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
MichalKubeček
Sounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Well, yes, but then you need to explain over and over why 15 is newer than 42 and why this was considered to be a good decision.. And while it's somewhat easy to explain all that in this list, openSUSE is also being discussed in so many other places so you can't really contain it and prevent people from making the wrong assumptions about this decision.
However, if you rename the whole thing then people will disassociate Leap/42 with Foobar/15 so no questions will be asked (at least not as many as we are asking right now)
I think also peaople saying the same.
For me, when it should be unconditional 15.x, the best is openSUSE Leap 15.x
Because it gives SLE, Tumbleweed and Leap. You can easily differnt between this "versions". It's very clearly and easy.
Why not just drop "Leap" as unnecessary baggage and have SLE, Tumbleweed and opensuse. I'm guessing there will be no more "Leap"s in development, only evolution due to keeping in line with SLE.
For me, when it should be unconditional 15.x, the best is openSUSE Leap 15.x
Because it gives SLE, Tumbleweed and Leap. You can easily differnt between this "versions". It's very clearly and easy.
Why not just drop "Leap" as unnecessary baggage and have SLE, Tumbleweed and opensuse. I'm guessing there will be no more "Leap"s in development, only evolution due to keeping in line with SLE.
+1
On 04/25/2017 06:11 PM, ianseeks wrote:
On Tuesday, 25 April 2017 07:19:56 BST Eric Schirra wrote:
Am 2017-04-25 00:29, schrieb Markos Chandras:
On 04/24/2017 11:14 PM, Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote: > On 04/24/2017 07:06 PM, Jan Engelhardt wrote: >> In a real company/product (like SLE), there would be a PR and >> sales >> department preventing from jumping backwards surely. Just because >> openSUSE does not have these two suddenly makes it ok? > > SUSE does have some of those people, I believe they chose to jump > from > 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
MichalKubeček
Sounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Well, yes, but then you need to explain over and over why 15 is newer than 42 and why this was considered to be a good decision.. And while it's somewhat easy to explain all that in this list, openSUSE is also being discussed in so many other places so you can't really contain it and prevent people from making the wrong assumptions about this decision.
However, if you rename the whole thing then people will disassociate Leap/42 with Foobar/15 so no questions will be asked (at least not as many as we are asking right now)
I think also peaople saying the same.
For me, when it should be unconditional 15.x, the best is openSUSE Leap 15.x
Because it gives SLE, Tumbleweed and Leap. You can easily differnt between this "versions". It's very clearly and easy.
Why not just drop "Leap" as unnecessary baggage and have SLE, Tumbleweed and opensuse. I'm guessing there will be no more "Leap"s in development, only evolution due to keeping in line with SLE.
Because as I have said previously those of us developing tumbleweed, sometimes need a generic way to separate between a change for all versions of tumbleweed and all versions of Leap and being able to reference Leap, rather then "next stable LTS service pack" is quite convenient.
We also finally have consistent branding between our two operating systems which are both supported equally based off the phrasing "Tumbleweed" and "Leap" check http://opensuse.org to see this I don't see why we should break this branding just because we decided to make a version jump backwards (Yes I agree in principle jumping backwards is rather silly, even more so then using 42 as a version).
I guess I'll save this text somewhere for the next time someone makes this comment without reading the thread in entirety.
On Monday, 24 April 2017 23:14:57 BST Simon Lees wrote:
On 04/25/2017 06:56 AM, Markos Chandras wrote:
On 04/24/2017 01:32 PM, Michal Kubecek wrote:
On Monday, 24 April 2017 12:07 Simon Lees wrote:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely. Just because openSUSE does not have these two suddenly makes it ok?
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is what triggered this change in the first place.
Right. But what openSUSE Board just decided to do is could be rather compared to the hypothetical (I sincerely hope) situation if in a few years our marketing guys said "we did some more research and apparently IT people are not as afraid of 13 and 14 as we thought, let's do SLE13 as next version (i.e. after 15)". Just skipping from 12 to 15 could be rather compared to skipping from 13 to 42.
Michal KubečekSounds like a lot of these problems could have been avoided if SLE simply went for 45 instead of 15. Honestly, that couldn't have been any worse than jumping backwards.
In such cases is almost always better to rename the project, in this case 'Leap' to something else, to signal this major change and avoid confusion. Just like it happened for 13.X and Leap. Because going backwards is a major change and we will have to explain the reasoning for quite a while.
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Do you need to keep Leap in the name anymore? It seems unnecessary as opensuse 15.x == opensuse leap 15.x - what is "Leap" for anymore, its totally irrelevant now as most people will call the releases opensuse 15.x. And they will get the message that its inline with SLE. KISS is the solution
But when we changed the name from openSUSE 13.X to openSUSE Leap it was because the way we develop openSUSE Leap with a SLE base is fundamentally different to the way we developed openSUSE in the past, we haven't changed the way were developing openSUSE here so there really is no reason to remove "Leap" as "Leap 15.X" will still be developed the same way "Leap 42.X" was.
Do you need to keep Leap in the name anymore? It seems unnecessary as opensuse 15.x == opensuse leap 15.x - what is "Leap" for anymore, its totally irrelevant now as most people will call the releases opensuse 15.x. And they will get the message that its inline with SLE. KISS is the solution
+1
Am 24.04.2017 um 12:07 schrieb Simon Lees:
On 04/24/2017 07:06 PM, Jan Engelhardt wrote:
In a real company/product (like SLE), there would be a PR and sales department preventing from jumping backwards surely.
SUSE does have some of those people, I believe they chose to jump from 12 to 15 which is
...not a jump backwards.
At least it was not, when I learned my math.
On 24/04/2017 10:30, Richard Brown wrote:
If you're referring to yourself as a "technical guy", I do not see any email from you asking any questions, nor making statements which would imply we should have consulted with you.
As another "Technical guy" who contributes a lot of his time to both packages and bug fixes, I would like to state that not only will this change negatively affect some packages but I'm of the opinion that this is a negative marketing decision. You only have to look at the responses in this thread to realize this. Oracle must be psychic in keeping the version of virtual box at openSUSE132. Try a referendum among openSUSE users and see who is in favor and who's against.
Dave Plater User plater
On 04/24/2017 09:58 AM, Richard Brown wrote:
On 24 April 2017 at 09:35, Rüdiger Meier sweet_f_a@gmx.de wrote:
Who is actually responsible for setting up the Leap repos, Ludwig?
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness, and approved it again once we had decided it was the right course forward.
The reason the announcement was sent when it was precisely because Ludwig is increasingly keen to get the repositories ready, and he needed everyone to know why they'd be versioned the way he's going to be versioning them.
BTW Wasn't there a vote about 42 being Leap's first *version* *number*? A version number *increases* over time otherwise it is no version number. We should not allow the board to ignore the fact that we want to have a version.
The long debate giving Leaps original naming and versioning was only ended when the community used the mailing-lists to clearly and vocally request that the Board step in and decide on the projects behalf.
Given the time pressure involved (Ludwig REALLY wanted to start setting up the projects some weeks ago) the Board felt it was in the projects best interest to continue in the same vein, rather than paralyse Ludwig and our Release Team by encouraging a debate which we weren't able to reach consensus over last time.
There is ONE consensus about version numbers: They have to count upwards (unless the project name changes too). Even some projects which are using random (public/marketing) "version number" like Windows have an internal, machine-readable version number which count upwards.
Our machine-readable version number is in /etc/os-release But your "decision" makes it completely useless. It's not possible to use that file from within scripts without hardcoding your insane logic and ideas. But that's impossible.
If other projects would also use such stupid version numbers like you then the whole world had to re-think how to upgrade packages. zypper, rpm, apt, ports, whatever would not work if more people would do it similar like our openSUSE board.
And that is, after all, one of the reasons why we have a Board, to make decisions the Project could otherwise have a very hard time making.
There was no hard decision to make. It's not hard to count numbers upwards ...
Generally speaking the Board will NEVER make a decision that everyone would like - because if the Board makes a universally liked decision then there was no reason to involve the Board in the first place.
Am Montag, 24. April 2017, 09:58:54 CEST schrieb Richard Brown:
Given the time pressure involved (Ludwig REALLY wanted to start setting up the projects some weeks ago) the Board felt it was in the projects best interest to continue in the same vein, rather than paralyse Ludwig and our Release Team by encouraging a debate which we weren't able to reach consensus over last time.
An announcement together with a poll would have avoided most of the frustration over here in the factory list....
And that is, after all, one of the reasons why we have a Board, to make decisions the Project could otherwise have a very hard time making.
Putting my PRINCE2 hat on, the board should be called when a project is not able to make a decision. In this case, there was never a request for decision on the table. Or even the knowledge that some rebranding is going on. So the integral part of a discussion beforehand is missing
Generally speaking the Board will NEVER make a decision that everyone would like - because if the Board makes a universally liked decision then there was no reason to involve the Board in the first place.
Sure, not everyone will like the decision. But a board should never make decisions w/o involving the project beforehand. We call this democracy.....and I do not mean north-corean style.
Cheers Axel
Am 24.04.2017 um 09:58 schrieb Richard Brown:
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness, and approved it again once we had decided it was the right course forward.
What about
openSUSE 150 openSUSE 151 openSUSE 152 openSUSE 160 ...
Solves both problems: It's clearly aligned with SLES15, SLES15SP1 (I'm sure the SLES people hate 15.1, because they tell the world not to call SLESxSPy "SLESx.y" all the time, and openSUSE would just do the contrary), it bigger than 42.3 and it's one less character to type in the repo names :-P
On 04/24/2017 07:49 PM, Stefan Seyfried wrote:
Am 24.04.2017 um 09:58 schrieb Richard Brown:
Ludwig is responsible, and the Board consulted with him and he approved the idea of Leap 15 before we considered it with any seriousness, and approved it again once we had decided it was the right course forward.
What about
openSUSE 150 openSUSE 151 openSUSE 152 openSUSE 160 ...
or maybe 42.15.0 42.15.1 42.15.2 42.16.0
pronounced as whatever you prefer "Leap 15.1", or "Leap 42.15.1" or just "42 15.1", or "Leap 15 SP1" :)
Solves both problems: It's clearly aligned with SLES15, SLES15SP1 (I'm sure the SLES people hate 15.1, because they tell the world not to call SLESxSPy "SLESx.y" all the time, and openSUSE would just do the contrary), it bigger than 42.3 and it's one less character to type in the repo names :-P
On 04/24/2017 05:05 PM, Rüdiger Meier wrote:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
Well according to the constitution [1] if you get support of 20% of the openSUSE members then yes you can trigger a replacement of the board. Personally I would have preferred to keep going up but understand the boards decision and wouldn't vote to replace them.
Yes Ludwig is responsible for setting up the repo's but he also probably consulted with the board during the process otherwise we probably should be looking for a new release manager.
BTW Wasn't there a vote about 42 being Leap's first *version* *number*? A version number *increases* over time otherwise it is no version number. We should not allow the board to ignore the fact that we want to have a version.
I expect at least 90% of openSUSE contributers would vote against decreasing/random version numbers. Would be really poor if we don't manage to stop this BS.
Well hopefully from now we will continue to go up in a sensible fashion, if it was known that SUSE would pick 15 for its next version when openSUSE picked 42 its likely we would have chosen 14 instead but we didn't and in 10 years time hopefully looking back 15 will have been the sensible choice.
1. https://en.opensuse.org/openSUSE:Board_election_rules#Forced_re-election:
On Monday, 24 April 2017 10:02 Simon Lees wrote:
Well hopefully from now we will continue to go up in a sensible fashion ... and in 10 years time hopefully looking back 15 will have been the sensible choice.
When you take a look at how many times the release scheme changed in last 10 years (each time with "we have it right this time and it's going to stay like this"), do you really believe in the vision I quoted above?
Personally, I find it more likely that in 10 years, people are going to see this "Leap Back" episode just one in a row of similar ad hoc changes, each having been presented as being set in stone for future generations. But, yes, I agree that in 10 years, nobody is probably going to be still angry about this particular change.
Michal Kubeček
On Mon, Apr 24, 2017 at 10:22 AM, Michal Kubecek mkubecek@suse.cz wrote:
On Monday, 24 April 2017 10:02 Simon Lees wrote:
Well hopefully from now we will continue to go up in a sensible fashion ... and in 10 years time hopefully looking back 15 will have been the sensible choice.
When you take a look at how many times the release scheme changed in last 10 years (each time with "we have it right this time and it's going to stay like this"), do you really believe in the vision I quoted above?
Personally, I find it more likely that in 10 years, people are going to see this "Leap Back" episode just one in a row of similar ad hoc changes, each having been presented as being set in stone for future generations. But, yes, I agree that in 10 years, nobody is probably going to be still angry about this particular change.
In our software build and install scripts we check for the openSUSE version. We use the information in /etc/os-release. When openSUSE went from 13.3 to 42.1, it was no logical issue because the version number increased. So simple tests of > or < still worked. The first big issue we had was with Tumbleweed, which uses the date of release as the version. It resulted in us having to track Tumbleweed things one way, and openSUSE/Leap another way. Nonetheless, within each version numbering system, the version numbers increased.
Is there another package or distribution that has used an occasionally decreasing version number? An example of Red Hat was given. But they changed the product name at the same time. They did not decrease the number of a product that had the same name. I would imagine that a version of 15 might make some sort of sense if Leap is dropped.
Perhaps it is time to disassociate the distribution name (which may or may not include a number) from the software release version. Microsoft have had this for a long time. The '10' in Windows 10 is not used at the code/packaging level to describe/detect the software version.
If the VERSION (or VERSION_ID?) in /etc/os-release is a numerically increasing number, I am okay. If it decreases, then maintenance becomes a bit harder. The PRETTY_NAME can be whatever, with whatever numbers or text makes you happy. But the actual version number should increase.
Isn't this type of fragmentation between Linux distros one of the reasons software products that support Linux usually only support a couple distros? How many 3rd party software suppliers will have to address this non-standard openSUSE-unique behavior?
On 2017-04-24 10:43, Roger Oberholtzer wrote:
In our software build and install scripts we check for the openSUSE version. We use the information in /etc/os-release. When openSUSE went from 13.3 to 42.1, it was no logical issue because the version number increased. So simple tests of > or < still worked. The first big issue we had was with Tumbleweed, which uses the date of release as the version. It resulted in us having to track Tumbleweed things one way, and openSUSE/Leap another way. Nonetheless, within each version numbering system, the version numbers increased.
Is there another package or distribution that has used an occasionally decreasing version number? An example of Red Hat was given. But they changed the product name at the same time. They did not decrease the number of a product that had the same name. I would imagine that a version of 15 might make some sort of sense if Leap is dropped.
Perhaps it is time to disassociate the distribution name (which may or may not include a number) from the software release version. Microsoft have had this for a long time. The '10' in Windows 10 is not used at the code/packaging level to describe/detect the software version.
You could renumber 42 as 14 or as a date string, similar to Tumbleweed. Using date string internally would be safer for the future. But you'd have to backport the change to 42.x
Otherwise, I would suggest to post the code to do version detection correctly in the same place where versions are listed, or externals will refuse to contemplate openSUSE in their packages. Just an opinion/guess.
On Monday 2017-04-24 10:22, Michal Kubecek wrote:
Personally, I find it more likely that in 10 years, people are going to see this "Leap Back" episode just one in a row of similar ad hoc changes, each having been presented as being set in stone for future generations. But, yes, I agree that in 10 years, nobody is probably going to be still angry about this particular change.
Certainly, any single event has a decaying importance as you say.
But the way it currently stands, openSUSE has a rather high *rate* of recurrence of "unusual" small-group decisions.
Dne pondělí 24. dubna 2017 9:35:32 CEST, Rüdiger Meier napsal(a):
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was
I'm not going to comment the decision itself, but what is Your idea of decision making process? We had elections recently. One should check and ask the candidates how they are going to lead the project, communicate their work and decisions and insist on their promises, democratic principles and openness. They received the trust and responsibility, so that they can take the decision. Legally. Hopefully we selected right people there. It doesn't help to loudly ask to kick them. There is the democratic possibility (linked recently) to do so. Noise on ML doesn't anyhow say how many people really wish so. Some are silent, some are not no the ML. Regarding broad voting, openSUSE is sponsored mainly by SUSE and its employees do most of the job. Who should make the decisions? Who pays? Do the job? Contribute a little? Use the software? Is publicly active? openSUSE is not fully community distro, it is highly depending on SLE and should share as much as possible with it. Which questions would You provide for a referendum? Numbering scheme? Length of support? How often new version is released? Default DE? Default browser? Wallpaper? What else? Something I don't care. Something I'm unable to decide as I'm not skilled in the field. For something I'm going to fight. :-) I don't say the topics should not be debated (Of course they should!), but the method can differ. The methods can differ, something is technical question or worth for experts. And finally someone must realize the decision and have the responsibility. Not easy.
Rüdiger Meier schrieb:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
Yes I am. I could have created the OBS project and continue with a version that I liked in the first place already. However, when it became clear that 43 no longer was the most obvious successor of 42 I've intentionally involved the board in this matter to evaluate the options.
cu Ludwig
On 04/24/2017 10:54 AM, Ludwig Nussel wrote:
Rüdiger Meier schrieb:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
Yes I am. I could have created the OBS project and continue with a version that I liked in the first place already. However, when it became clear that 43 no longer was the most obvious successor of 42
Why instead of "not most obvious" we get now the "least obvious"?
I've intentionally involved the board in this matter to evaluate the options.
Please! Re-think this issue. We need an increasing VERSION_ID in /etc/os-release like any other Distro on this planet.
cu, Rudi
On 24 April 2017 at 11:01, Rüdiger Meier sweet_f_a@gmx.de wrote:
On 04/24/2017 10:54 AM, Ludwig Nussel wrote:
Rüdiger Meier schrieb:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
Yes I am. I could have created the OBS project and continue with a version that I liked in the first place already. However, when it became clear that 43 no longer was the most obvious successor of 42
Why instead of "not most obvious" we get now the "least obvious"?
I've intentionally involved the board in this matter to evaluate the options.
Please! Re-think this issue. We need an increasing VERSION_ID in /etc/os-release like any other Distro on this planet.
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Given it's optional status, I think your suggestion that we should rethink this because it won't be forever increasing in /etc/os-release is not sufficient justification for Ludwig or anyone to rethink this.
Regards,
On 04/24/2017 11:09 AM, Richard Brown wrote:
On 24 April 2017 at 11:01, Rüdiger Meier sweet_f_a@gmx.de wrote:
On 04/24/2017 10:54 AM, Ludwig Nussel wrote:
Rüdiger Meier schrieb:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
Yes I am. I could have created the OBS project and continue with a version that I liked in the first place already. However, when it became clear that 43 no longer was the most obvious successor of 42
Why instead of "not most obvious" we get now the "least obvious"?
I've intentionally involved the board in this matter to evaluate the options.
Please! Re-think this issue. We need an increasing VERSION_ID in /etc/os-release like any other Distro on this planet.
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Given it's optional status, I think your suggestion that we should rethink this because it won't be forever increasing in /etc/os-release is not sufficient justification for Ludwig or anyone to rethink this.
Come on, your argumentation gets more ridiculous.
The field may be optional, but we provide it already. So IMO for openSUSE it is not optional anymore, unless we want to break even more existing usage. According the definition, once we have this field, it is defined as "suitable for processing by scripts". This includes that "sort --version-sort" should give us a useful order of Leap releases.
cu, Rudi
Am 24.04.2017 um 11:09 schrieb Richard Brown:
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Oh, then go ahead and remove everything 'clearly documented as optional' from os-release. Saves a lot of space!
NAME="openSUSE Leap" ID=opensuse
That's it
m(
24.04.2017 21:08, Stefan Seyfried пишет:
Am 24.04.2017 um 11:09 schrieb Richard Brown:
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Oh, then go ahead and remove everything 'clearly documented as optional' from os-release. Saves a lot of space!
NAME="openSUSE Leap" ID=opensuse
That's it
According to manual, both are optional. "If not set, defaults to ..." for both fields.
Am 24.04.2017 um 20:14 schrieb Andrei Borzenkov:
24.04.2017 21:08, Stefan Seyfried пишет:
NAME="openSUSE Leap" ID=opensuse
That's it
According to manual, both are optional. "If not set, defaults to ..." for both fields.
not the manual that's shipped with openSUSE 14.2
On 2017-04-24 20:16, Stefan Seyfried wrote:
Am 24.04.2017 um 20:14 schrieb Andrei Borzenkov:
24.04.2017 21:08, Stefan Seyfried пишет:
NAME="openSUSE Leap" ID=opensuse
That's it
According to manual, both are optional. "If not set, defaults to ..." for both fields.
not the manual that's shipped with openSUSE 14.2
Eh... Um.... What? :-o :-?
On 04/24/2017 08:08 PM, Stefan Seyfried wrote:
Am 24.04.2017 um 11:09 schrieb Richard Brown:
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Oh, then go ahead and remove everything 'clearly documented as optional' from os-release. Saves a lot of space!
NAME="openSUSE Leap" ID=opensuse
That's it
Seriously, it would be better to remove all version info from /etc/os-release than counting backwards.
cu, Rudi
On 24/04/17 02:23 PM, Rüdiger Meier wrote:
On 04/24/2017 08:08 PM, Stefan Seyfried wrote:
Am 24.04.2017 um 11:09 schrieb Richard Brown:
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Oh, then go ahead and remove everything 'clearly documented as optional' from os-release. Saves a lot of space!
NAME="openSUSE Leap" ID=opensuse
That's it
Seriously, it would be better to remove all version info from /etc/os-release than counting backwards.
cu, Rudi
I like openSUSE 15 LTS
Roman
On 25/04/2017 02:07, Roman Bysh wrote:
On 24/04/17 02:23 PM, Rüdiger Meier wrote:
On 04/24/2017 08:08 PM, Stefan Seyfried wrote:
Am 24.04.2017 um 11:09 schrieb Richard Brown:
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Oh, then go ahead and remove everything 'clearly documented as optional' from os-release. Saves a lot of space!
NAME="openSUSE Leap" ID=opensuse
That's it
Seriously, it would be better to remove all version info from /etc/os-release than counting backwards.
cu, Rudi
I like openSUSE 15 LTS
Roman
That might work but then all of Richards positive marketing of the Leap brand will be wasted and it will have to start over again. Dave P
On Tuesday, 25 April 2017 07:18:53 BST Dave Plater wrote:
On 25/04/2017 02:07, Roman Bysh wrote:
On 24/04/17 02:23 PM, Rüdiger Meier wrote:
On 04/24/2017 08:08 PM, Stefan Seyfried wrote:
Am 24.04.2017 um 11:09 schrieb Richard Brown:
We could follow the documentation and remove the VERSION_ID field entirely from our /etc/os-release file
https://www.freedesktop.org/software/systemd/man/os-release.html
After all, it's clearly documented as 'optional'
Oh, then go ahead and remove everything 'clearly documented as optional' from os-release. Saves a lot of space!
NAME="openSUSE Leap" ID=opensuse
That's it
Seriously, it would be better to remove all version info from /etc/os-release than counting backwards.
cu, Rudi
I like openSUSE 15 LTS
Roman
That might work but then all of Richards positive marketing of the Leap brand will be wasted and it will have to start over again. Dave P
The "leap" brand is tarnished now anyway, opensuse is a much bigger and more valuable brand
That might work but then all of Richards positive marketing of the Leap brand will be wasted and it will have to start over again. Dave P
The "leap" brand is tarnished now anyway, opensuse is a much bigger and more valuable brand
Whatever you mean with "marketing" dropping the word leap will make no difference besides making it more understandable especially as the product is not changing (this time)
On 25/04/2017 10:42, ianseeks wrote:
I like openSUSE 15 LTS
Roman
That might work but then all of Richards positive marketing of the Leap brand will be wasted and it will have to start over again. Dave P
The "leap" brand is tarnished now anyway, opensuse is a much bigger and more valuable brand
I think that Richard will enjoy the challenge of promoting openSUSE:Leap:15 (Not quite sure but I thought I saw the implication that it will start without a ".0" or ".1") and may well succeed. I still can't see a proper reason for the jump backwards though. Leap is already associated with enterprise Suse but maybe the controversy that will be created will make more people take note. I still think it's an unnecessary risk. From a packager's point there's no macro changes and I've got used to using %sle_version combined with %is_opensuse, I'm glad that %leap_version was never implemented, it was bad enough coping with %suse_version's backward jump from 1320 to 1315. The only packages I can find with 42. versions are branding and theme packages the majority of which still have 42.1 as the version in 42.2. I do detect an element of bullying though.
Dave P
On Mon, Apr 24, 2017 at 10:54 AM, Ludwig Nussel ludwig.nussel@suse.de wrote:
Yes I am. I could have created the OBS project and continue with a version that I liked in the first place already. However, when it became clear that 43 no longer was the most obvious successor of 42 I've intentionally involved the board in this matter to evaluate the options.
If one goes to 15 as the next release, then I think the only recourse is to remove Leap from the name. Then plain old openSUSE will go from 13.3 to 15.1. Only openSUSE/Leap will have the unfortunate 42 numbering. I am guessing it is expected that openSUSE will probably be called something else when the 15 series hits 41, and then will need a new version number scheme again. Or will it then skip from 41 to 43? But that's long in the future, no?
On Mon, Apr 24, 2017 at 10:54:14AM +0200, Ludwig Nussel wrote:
Rüdiger Meier schrieb:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Rapidly losing faith in that board. Did they not chose "Leap" for signifying the leap forwards? Reinterpreting that as leaping backwards... yeah I can already see the news headlines.
Can't we just kick the board? Or continue with something > 42 as it was planned. Lets just ignore this non-sense announcement. Who is actually responsible for setting up the Leap repos, Ludwig?
Yes I am. I could have created the OBS project and continue with a version that I liked in the first place already. However, when it became clear that 43 no longer was the most obvious successor of 42 I've intentionally involved the board in this matter to evaluate the options.
Thinking about some more we could have pretty much just left it at 43, the artificial SLES number change due to "bad number" avoidance does not hit 43, unless you want to avoid "prime numbers". :(
Ciao, Marcus
Am 24.04.2017 um 11:08 schrieb Marcus Meissner:
On Mon, Apr 24, 2017 at 10:54:14AM +0200, Ludwig Nussel wrote:
Rüdiger Meier schrieb:
On 04/23/2017 12:51 AM, Jan Engelhardt wrote:
On Saturday 2017-04-22 13:37, Richard Brown wrote:
After considering the pros and cons of all the options however, the decision has been that Leap 15 will be our next version.
Thinking about some more we could have pretty much just left it at 43, the artificial SLES number change due to "bad number" avoidance does not hit 43, unless you want to avoid "prime numbers". :(
+1
After we've explained Tumbleweed vs. Leap to everyone, it will be a hard sell that 15 is newer than 42. In addition to any technical version numbering problems it causes, it's a marketing disaster.
It would've been a good idea had this been thought of when introducing the Leap brand - now it is too late to go backwards IMO. 13.x is out of support, so that is no excuse for going with 15.
Regards, Andreas
On 04/22/2017 09:07 PM, Richard Brown wrote:
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
45 was also considered, as were some frankly hilarious ideas that made me worry about my own sanity and that of my fellow contributors.
Seen as we are all people, and people don't seem to like change many people are bound to be unhappy, can you perhaps counter some of this unhappyness by publishing some of the "hilarious ideas" for my oh no I guess I mean our personal enjoyment :-P, Maybe its not even too late for a lightning talk at osc17 covering some of the stranger proposals.
Simon Lees composed on 2017-04-23 08:21 (UTC+0930)
Seen as we are all people, and people don't seem to like change many people are bound to be unhappy, can you perhaps counter some of this unhappyness by publishing some of the "hilarious ideas" for my oh no I guess I mean our personal enjoyment :-P, Maybe its not even too late for a lightning talk at osc17 covering some of the stranger proposals.
Leap 42.3 Leaq 15 Leep 16 Leeq 17 Lear 18
Just as good as leaping backwards from 42.3 to 15. Let the next board generations figure out what to do next. What was tradition ever good for anyway? GTE, Woolworth, Ben Franklin, Goldstar, Howard Johnson, Morton Foods, Oldsmobile, Rambler, Studebaker, Plymouth, Hudson, Packard, Douglas Aircraft, Eastern Airlines, TWA, Pan American World Airways, Amoco, Gulf Oil, Rexall, A & W Drive In, Burma Shave... :-p
On 22/04/17 08:16 PM, Felix Miata wrote:
Leap 42.3 Leaq 15 Leep 16 Leeq 17 Lear 18
Just as good as leaping backwards from 42.3 to 15. Let the next board generations figure out what to do next. What was tradition ever good for anyway? GTE, Woolworth, Ben Franklin, Goldstar, Howard Johnson, Morton Foods, Oldsmobile, Rambler, Studebaker, Plymouth, Hudson, Packard, Douglas Aircraft, Eastern Airlines, TWA, Pan American World Airways, Amoco, Gulf Oil, Rexall, A & W Drive In, Burma Shave... :-P
What do you want to be that there will be another change in version identification within the next ... says ... 25 years?
Assuming that Linux isn't added to the above list.
On 22/04/2017 13:37, Richard Brown wrote:
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@opensuse.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@opensuse.org thread.
Regards,
Richard Brown on behalf of the openSUSE Board
Not once in this message is there a positive reason for this change but in this thread there are many negative marketing effects put forward. This brings to mind the saying "If it ain't broke don't fix it!" Dave Plater
On 04/22/2017 01:37 PM, Richard Brown wrote:
openSUSE Leap 15
As I didn't see my position in the other replies:
I don't care about the number - so I can happily live with 15. Thanks for the reasoning. ;-)
Have a nice day, Berny
On 22.04.17 13:37 Richard Brown wrote:
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
I do not understand why so many people are opposing to this naming scheme. To me it seems reasonable to align with SLE. And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Johannes
On Sunday, 23 April 2017 16:59:33 BST Johannes Kastl wrote:
On 22.04.17 13:37 Richard Brown wrote:
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
I do not understand why so many people are opposing to this naming scheme. To me it seems reasonable to align with SLE. And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Johannes
I think most people see the sense in it in order to keep them aligned. The annoyance is really down to all the spin and childish justification we had a few years ago with the numbering of Leap to 42 which has proved to a mistake. Its the same scenario when a company gets a new marketing team and they have no idea of the current value their brand has and thinks up useless new ideas. Basically if you've got a strong brand, you keep it and improved it, a bit like rebranding KDE5 to Plasma - all that goodwill in "KDE " lost and people still refer to plasma as KDE5 because it makes sense.
Am 23.04.2017 um 17:59 schrieb Johannes Kastl:
And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Seems to work well enough for Fedora...
And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Seems to work well enough for Fedora...
Fedora Rawhide is closer to the old Factory than Tumbleweed, so the analogy doesn't hold. Fedora XYZ is the distribution, with Rawhide being the "development" version. openSUSE has two distributions (Leap and Tumbleweed) so they should have separate names.
On 25.04.2017 04:36, Aleksa Sarai wrote:
And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Seems to work well enough for Fedora...
Fedora Rawhide is closer to the old Factory than Tumbleweed, so the analogy doesn't hold. Fedora XYZ is the distribution, with Rawhide being the "development" version. openSUSE has two distributions (Leap and Tumbleweed) so they should have separate names.
You're totally and deliberately missing the point.
The assertion was "We need 'openSUSE Leap' as distribution name because people would confuse 'openSUSE 151' (the distribution) with the openSUSE project".
And that's just totally wrong. As fedora has proven.
Stefan Seyfried composed on 2017-04-24 20:13 (UTC+0200):
Johannes Kastl compose:
And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Seems to work well enough for Fedora...
Fedora's "releases" are much more like rolling releases than releases in the sense most of us use the term. Its releases routinely update a number of high profile packages to latest upstream releases regardless whether any carry an LTS designation. e.g. F25 came out close to 42.2 release 5 months ago with kernel 4.8.6, but now is on 4.10.10; Xorg server was 1.19.0rc, now is at 1.19.3; Plasma was 5.8.1, now 5.9.4.
On 24/04/17 11:31 PM, Felix Miata wrote:
Stefan Seyfried composed on 2017-04-24 20:13 (UTC+0200):
Johannes Kastl compose:
And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Seems to work well enough for Fedora...
Fedora's "releases" are much more like rolling releases than releases in the sense most of us use the term. Its releases routinely update a number of high profile packages to latest upstream releases regardless whether any carry an LTS designation. e.g. F25 came out close to 42.2 release 5 months ago with kernel 4.8.6, but now is on 4.10.10; Xorg server was 1.19.0rc, now is at 1.19.3; Plasma was 5.8.1, now 5.9.4.
Somewhere between "Indeed", and "yes-but".....
I am notionally running 42.1 In the kernel side I am at 4.10.12, xorg-x11-server-7.6, and many other packages such as Mozilla, LibreOffice and of course the photography tools I use are up there with the 'latest and greatest'. As for "plasma", well that whole thing has me confused so I'm sticking with what I understand. (I'm sure I'm about to be deluged in advice...)
For me, "42.1" is like a rolling release .... as far as the packages that matter to me are concerned[1].
Regular readers will be aware that I've pointed out my use of the Kernel_Stable repository. All these other 'latest and greatest' are also from repositories that I've configured.
I'm sure there are people who will shout me down for using this approach, but lets face it, there are many of us who configure extra repositories for a variety of reasons, and I'm sure that getting 'the latest and greatest' for application packages rates high among them. I'm pretty sure that is the case for the few other photo enthusiasts I correspond with.
To my mind this makes the ability to point at extra repositories one of the winning facilities of the mainstream versions of Linux. it's not like downloading a random package out of the Microsoft domain for Windows users, these repertoires are either maintained or you can find the owners responsible. I've often contacted repository owners and had meaningful exchanges with them. And to be quite frank they have been more responsive than the supposed "support" of the Big Name/Big Iron support that is run on a Pay-For (and pay a LOT for at that) basis. On top of that this (and the other opensuse lists I've subscribed to) have been more use to me that the Big name/Big Iron support lines were when I was in that the context to be using them.
(That major firms are slow to grok this is disappointing.)
[1] My debugging of why Linda had problems with setting up thin pools using YaST is a an example. I don't have an updated libstorage because YaST isn't something that matters to me.
On 25 April 2017 at 14:49, Anton Aylward opensuse@antonaylward.com wrote:
On 24/04/17 11:31 PM, Felix Miata wrote:
Stefan Seyfried composed on 2017-04-24 20:13 (UTC+0200):
Johannes Kastl compose:
And the differentiation between openSUSE (the project), Tumbleweed and Leap does no longer work if we drop the "leap"...
Seems to work well enough for Fedora...
Fedora's "releases" are much more like rolling releases than releases in the sense most of us use the term. Its releases routinely update a number of high profile packages to latest upstream releases regardless whether any carry an LTS designation. e.g. F25 came out close to 42.2 release 5 months ago with kernel 4.8.6, but now is on 4.10.10; Xorg server was 1.19.0rc, now is at 1.19.3; Plasma was 5.8.1, now 5.9.4.
Somewhere between "Indeed", and "yes-but".....
I am notionally running 42.1 In the kernel side I am at 4.10.12, xorg-x11-server-7.6, and many other packages such as Mozilla, LibreOffice and of course the photography tools I use are up there with the 'latest and greatest'. As for "plasma", well that whole thing has me confused so I'm sticking with what I understand. (I'm sure I'm about to be deluged in advice...)
For me, "42.1" is like a rolling release .... as far as the packages that matter to me are concerned[1].
Regular readers will be aware that I've pointed out my use of the Kernel_Stable repository. All these other 'latest and greatest' are also from repositories that I've configured.
I'm sure there are people who will shout me down for using this approach, but lets face it, there are many of us who configure extra repositories for a variety of reasons, and I'm sure that getting 'the latest and greatest' for application packages rates high among them. I'm pretty sure that is the case for the few other photo enthusiasts I correspond with.
To my mind this makes the ability to point at extra repositories one of the winning facilities of the mainstream versions of Linux. it's not like downloading a random package out of the Microsoft domain for Windows users, these repertoires are either maintained or you can find the owners responsible. I've often contacted repository owners and had meaningful exchanges with them. And to be quite frank they have been more responsive than the supposed "support" of the Big Name/Big Iron support that is run on a Pay-For (and pay a LOT for at that) basis. On top of that this (and the other opensuse lists I've subscribed to) have been more use to me that the Big name/Big Iron support lines were when I was in that the context to be using them.
(That major firms are slow to grok this is disappointing.)
My feelings on additional repositories are well documented. TL;DR - They are a bad idea when not done properly. I do not feel we are doing them properly right now, and I'm not sure the effort of doing them properly is justified.
https://speakerdeck.com/sysrich/distribute-or-die-arguing-against-additional...
My feelings on how rolling releases are one of the best things ever is also well documented, especially how rolling releases done properly (like Tumbleweed) undermine a lot of the justifications for additional repositories.
https://speakerdeck.com/sysrich/fosdem-2017-how-i-learned-to-stop-worrying-a...
I really think the following rule applies:
"In order to be able to move ANYTHING quickly, you need to be able to move EVERYTHING quickly"
or in other words, if you want to look at a 11000+ codebase, close your eyes and randomly pick one package to keep up with upstream, you need to have the tooling, skills, capabilities, and technology to potentially move all 10999 other packages in order to facilitate that upgrade.
The 'stable base PLUS additional repositories' model is proven, through hard experience through Pre 2014 Tumbleweed that it just_does_not_work.
And given how bloody awesome we are with OBS and additional repositories, I think this is a lesson we can probably take as fact.
Leap's unique model shows you can make something work, if you are not religious about the stable base - occasional, facilitatory changes to the SLE base helps us get Leap in the shape we want it to be. But also in Leap there is the tacit understanding that sometimes we just cannot upgrade something to the latest version in a way that will work with Leap. It's a fact of life for conservative distributions.
SLE's model, with modules and extensions that are more modular than what we do in Leap and Tumbleweed, does work, but has significantly stricter controls in place - very specific packages only with very specific dependency chains can be delivered safely in this way. As a result, the scope of SLE plus it's modules is a tiny fraction of Leap or Tumbleweed in comparison, so I don't think it really addresses the scope of 'getting software in the hands of users' the way you suggest we should focus on.
So, in short, I'm happy you are happy with your approach. I respect anyone who supports your approach and wish them a lot of luck & patience. But I won't support them beyond that, because I think they're walking a path we've been down, screwed up, broke everything, fixed everything, and moved on from.
On Tue, Apr 25, 2017 at 11:29 AM, Richard Brown RBrownCCB@opensuse.org wrote:
My feelings on how rolling releases are one of the best things ever is also well documented, especially how rolling releases done properly (like Tumbleweed) undermine a lot of the justifications for additional repositories.
https://speakerdeck.com/sysrich/fosdem-2017-how-i-learned-to-stop-worrying-a...
But it can create the opposite problem.
In security:forensics I have to have links to some older dependencies because upstream for the packages I care about hasn't added support for the latest and greatest dependency.
Thus, there are some packages I can't send to factory because they either won't compile or won't run without the older version of the dependency
Greg
-- Greg Freemyer
On 04/26/2017 02:22 AM, Greg Freemyer wrote:
On Tue, Apr 25, 2017 at 11:29 AM, Richard Brown RBrownCCB@opensuse.org wrote:
My feelings on how rolling releases are one of the best things ever is also well documented, especially how rolling releases done properly (like Tumbleweed) undermine a lot of the justifications for additional repositories.
https://speakerdeck.com/sysrich/fosdem-2017-how-i-learned-to-stop-worrying-a...
But it can create the opposite problem.
In security:forensics I have to have links to some older dependencies because upstream for the packages I care about hasn't added support for the latest and greatest dependency.
Thus, there are some packages I can't send to factory because they either won't compile or won't run without the older version of the dependency
Greg
The downside there is we are in the process of creating Leap 15 from whats currently in tumbleweed, so if it not building in tumbleweed at the moment, it likely won't build in Leap 15 without extra effort to add multiple versions anyway which could possibly be done in tumbleweed already.
On 2017-04-25 17:29, Richard Brown wrote:
On 25 April 2017 at 14:49, Anton Aylward <> wrote:
I'm sure there are people who will shout me down for using this approach, but lets face it, there are many of us who configure extra repositories for a variety of reasons, and I'm sure that getting 'the latest and greatest' for application packages rates high among them. I'm pretty sure that is the case for the few other photo enthusiasts I correspond with.
This is absolutely true. There are many Leap (or equivalent distributions) users that do it that way.
My feelings on additional repositories are well documented. TL;DR
- They are a bad idea when not done properly. I do not feel we are
doing them properly right now, and I'm not sure the effort of doing them properly is justified.
https://speakerdeck.com/sysrich/distribute-or-die-arguing-against-additional...
And
I absolutely disagree on this.
My feelings on how rolling releases are one of the best things ever is also well documented, especially how rolling releases done properly (like Tumbleweed) undermine a lot of the justifications for additional repositories.
https://speakerdeck.com/sysrich/fosdem-2017-how-i-learned-to-stop-worrying-a...
Of
course I also disagree on this, absolutely.
So, in short, I'm happy you are happy with your approach. I respect anyone who supports your approach and wish them a lot of luck & patience. But I won't support them beyond that, because I think they're walking a path we've been down, screwed up, broke everything, fixed everything, and moved on from.
Well, let's hope that the majority of maintainers do not think your way.
On Sat, Apr 22, 2017 at 7:37 AM, Richard Brown RBrownCCB@opensuse.org wrote:
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.
This statement concerns me more than anything else. What about all the people who build solutions around openSUSE or for it? We *just* managed to figure out the new mess that is SUSE versioning, and now you want to break us again?
The number of conditionals I need for supporting the SUSE platform keeps growing with each release, and that's extremely aggravating.
Hi,
On Sat, Apr 22, 2017 at 2:37 PM, Richard Brown RBrownCCB@opensuse.org wrote:
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
What is the reason for not moving to 15 as an internal version number, e.g. in the RPM macros and using 43.x in version numbers that are communicated to end users?
As a packager, I need to be up to date with various RPM building techniques, macros and best practices, one more is not going to make a lot of difference.
As an end user, I would appreciate strictly incrementing version numbers, as it gives me a clear sense which version is the most recent one.
Robert
Robert Munteanu wrote:
What is the reason for not moving to 15 as an internal version number, e.g. in the RPM macros and using 43.x in version numbers that are communicated to end users?
Just to be consistent. Well, Leap 42.x was a fault and this corrects it. Personally I appreciate going with 15.x.
As a packager, I need to be up to date with various RPM building techniques, macros and best practices, one more is not going to make a lot of difference.
Well, many openSUSE project members are complaining that there's a lack of contributors. You might be familiar with all of the above. But this whole RPM macro set is black magic for occasional contributors. Adding more does demotivates anyone who wants to give a helping hand.
Ciao, Michael.
On 04/24/2017 08:52 PM, Michael Ströder wrote:
Robert Munteanu wrote:
What is the reason for not moving to 15 as an internal version number, e.g. in the RPM macros and using 43.x in version numbers that are communicated to end users?
Just to be consistent.
Well, Leap 42.x was a fault and this corrects it.
No, Leap 42.x was just ugly and ridiculous but no real problem. Now 15.x is a fault.
Personally I appreciate going with 15.x.
As a packager, I need to be up to date with various RPM building techniques, macros and best practices, one more is not going to make a lot of difference.
Well, many openSUSE project members are complaining that there's a lack of contributors. You might be familiar with all of the above. But this whole RPM macro set is black magic for occasional contributors. Adding more does demotivates anyone who wants to give a helping hand.
Ciao, Michael.
Why this is a negative marketing move.
On 22/04/2017 13:37, Richard Brown wrote:
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.
After two years Leap is an established brand and it is common knowledge that it is an LTS distribution that follows SUSE Linux Enterprise.
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.
The change from 4x.x to 1x.x will not make the perception of Leap anymore linked to SLE than it already is, in fact as you can see from comments in this thread it will give the impression of incompetence and will be a negative perception.
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).
I also noted your comment in another thread that Leap is now targeting power users when one of openSUSE's main features is easy configuration with YasT. This feature is easier to use than window's control panel.
You promote this decision as a positive move, it is not. Please tell me why I'm wrong. Thank you Dave Plater
On Sat, Apr 22, 2017 at 7:37 AM, Richard Brown RBrownCCB@opensuse.org wrote:
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
Every release gets a code name. I vote for "pathological".
It is a term used in physics to describe events for which we have no underlying foundation theory and thus even if it is true, we gain no predictive power. Water dowsing (to determine where to drill a well for water) is one example.
Then when openSUSE Leap 16 comes out, a code name of "sanity" might finally be appropriate.
Greg
-
Aleksa Sarai -
Andreas Färber -
Andrei Borzenkov -
Anton Aylward -
Axel Braun -
Axel Braun
-
Bernhard M. Wiedemann -
Bernhard Voelker -
Carlos E. R. -
Daniele -
Dave Plater -
dieter -
Eric Schirra -
Felix Miata -
Greg Freemyer -
ianseeks -
James Knott -
Jan Engelhardt -
Johannes Kastl -
Johannes Meixner -
Karl Sinn -
Ken Schneider - Factory -
Ludwig Nussel -
Marco Calistri -
Marcus Meissner -
Markos Chandras -
Mathias Homann -
Michael Ströder -
Michal Kubecek -
Neal Gompa -
Patrick Shanahan -
Richard Brown -
Robert Kaiser -
Robert Munteanu -
Robin Klitscher -
Roger Oberholtzer -
Roman Bysh -
Rüdiger Meier -
Simon Lees -
Stefan Seyfried -
Stephan Kulow -
Theo Chatzimichos -
Tomas Chvatal -
Vojtěch Zeisek