On 25 April 2017 at 07:34, Roger Oberholtzer
On Tue, Apr 25, 2017 at 12:47 AM, Richard Brown
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org