It’s a brilliant PR coup. openSUSE will be in the news …
I understand some of the technical reasons, but I feel pity for the person, who has to explain this to the rest of the world.
Hi
Package alignment (release macros) will be much easier…
As always, those who do decide… now just need to get a package hub up and running for openSUSE and then will cut down on all those long repo lists for the folks that want the latest and greatest from Tumbleweed built for Leap…
We “LEAP” forward from 13.2 to 42.1 !
We “LEAP” backwards from 42.3 to 15 !!
Cool!
I don’t know of any other product that is so original, why should versioning be linear?
We will pioneer time warp proving “back in time” is always a step forward!
Future historians will need 4D (yes, you need to account for the 4th dimension) to describe openSUSE history…
More seriously though…
The packaging version doesn’t have to be identical to the public name version… They’re both labels and don’t have to have any meaning beyond what is granted (Plenty of labels, maybe the majority of labels that exist don’t have any underlying meaning). So, for instance what has existed in the MSWindows world since forever is to name a version after a place very early which is there forever and never seen by the Consumer, but the public name (eg XP, Vista, etc) is something that can be assigned on a whim, based on marketing and managing the public’s consciousness. So, there can be excellent reasons for aligning openSUSE versions with SLE, but I don’t know that means that development and maintenance necessarily forces the same public name for the product.
No need to pity me, but please help by repeating what I already said in that thread in terms of an explanation. I will greatly appreciate any and all help getting the message out
I actually think there is an even better way we could deal with the version naming problems.
We could, instead, name the next version openSUSE Windows 3.1, after which we could follow with openSUSE WFWG 3.11, and then – when KDE upstream devs have finished removing all things we are used to using over the years, including any way at all to even log in to the GUI – we could have openSUSE KD-DOS 1.0.
Apart from it’s a complete lie that this decision will cost major work in spec files.
suse_version for Leap 42.1 was 1315, same as SLE. It was 1320 for openSUSE 13.2. Its 1330 for Tumbleweed.
so right now all of our specs have a complicated mess of suse_version, sle_version, leap_version, is_opensuse, and a pile of weird <>1320 rules to stop slashing with openSUSE 13.2 even though leap 42.2 is further ahead
This decision means we can deprecate leap_version, vastly simplify our spec files, and the best bit? We can increment leap_version to whatever the heck we want during the transition, so nothing should break in the meantime.
sure, it’s not as nice a story with salt stack and puppet, but on the flip side, all of my salt states are a mess of similarly messed up conditionals around SLE 12 and Leap 42 and now I will be able to tidy them all up, so I quite like the work involved - especially as I have like a year to prepare for it.
… which the Devs hope will be a one-time experience, short term pain for long term gain, once the version numbers are aligned and into the future – as Richard pointed out.
Besides, my clients are intelligent enough to understand when I explain such things to them.
I did not think 42.x the optimal approach, but it was not something I would complain about. I like the return to 15.
Having typed that, IMHO those doing most the work should have the final say on the versioning, and happily (for my views) they have now settled on v.15. I have my fingers crossed they consistently go down this new versioning path, incrementing nominally from 15 per their current plan.
Honestly, I’m starting to consider bailing to another distribution that doesn’t constantly break things or turn users into guinea pigs for their enterprise offering - one that would offer an actual LTS version instead of a make-pretend one.
The amount of time I’ve had to spend in fixing issues and dealing with things like BTRFS (first time since MurderFS that I’ve actually had catastrophic data loss - thank you backups for saving me this time) since Leap came out is just too god **** much. It’s time I’d rather be spending with my child or something productive.
Migrating to something else starts to look better each day.
May be a point but, I suspect that, most customers aren’t really so interested in the sequence of version numbers.
I’ll put on my thinking cap and try to remember if DEC ever had this issue with RSX-11M/M+, RSTS/E, VAX/VMS or TOPS-10/20.
I suspect that other industries such as Telecommunications never suffer this issue because, the ITU-T and 3GPP specifications are always nicely incremented – in the case of 3GPP at 3 monthly intervals, with each plenary session . . .
On the other hand, you seem to understand ‘sed’ – therefore, assuming that a reasonably generic script exists, what’s the issue?
