At first I want to say that the new versioning scheme on itself is just fine. Nothing really wrong about it to go with.
However from a packaging and distributing point of view it’s very frustrating to go with how the single parts of GNOME handle the versioning. I honestly think that GNOME should care about this a bit more.
Hi.
I’m doing the pre-releases (up to finals) for Arch Linux in the FCGU repo for a while now. So I’m not entirely new to it and how to deal with this situation (but also far from perfect).
Intro
In the “old days” it was just easy.
3.37.95 < 3.37.99 < 3.38.0 < 3.38.1 < 3.38.2
This was the same for GNOME versioning as well as package versioning.
With the new scheme we have this:
GNOME tracker
3.4.0.beta < 3.4.0.rc < 3.4.0 < 3.4.1 < 3.4.2
FCGU Package of it
3.4.0beta < 3.4.0rc < 3.4.0 < 3.4.1 < 3.4.2
GNOME adwaita-icon-theme
43.beta < 43.beta.1 < 43
FCGU Package of it
43.beta < 43.beta1 < 43.0
And so on. there are sometimes even more advanced ones who go 42.0.1 instead of 42.1 directly. But I’m OK with that.
So much to the intro. Lets face the
Problems
1. Package managers need to workaround versioning
As you might have noticed, the versions of my (and Archs) packages differ from the actual GNOME versioning. that’s because, for example in Tracker 3.4.0.rc is the version before 3.4.0, but for pacman 3.4.0.rc is greater then 3.4.0. This isn’t a bug, but intentional. This can be a problem in meson, too. By now I do workaround versioning incompatibilities where possible (Same goes for other distros, like fedora). The real problem is:
2. Inconsistency around projects and versions
As you have maybe noticed each project does it’s own versioning. Some do use X.Y.{alpha,beta,rc,0}, some X.Y.Z{.alpha,.beta,.rc}, some X.{alpha,beta,rc,0}. That’s something I could deal with, but I can’t, because not only is it inconsistent between project, but also between versions. For example the final version of adwaita-icon-theme 42 series was 42.0, so what’s the final version of the 43 series? You guessed it: “43”! That’s yet again a big deal, because I do pre-releases and 43.rc > 43. Would I have known that the final version this time would become a release without .0, I would have chosen the package version 43rc, because 43rc < 43. But since I can’t look into the future this is an situation where the user won’t get a good experience and needs to downgrade the package.
My wishes
I wish for the future that versioning scheme will become consistent, not only across versions, but in the best case also across projects. I don’t expect the 44 to be the version number for every software. I’d like to have however there there will be a rule that every .alpha/.beta/.rc will lead to either a .0 or no extension, not both of them. That
Epilogue
To address this. I’m not mad about something and I don’t want to start a war. This is entirely to show my point of view, tell the frustrating bits and pieces. I also don’t want to target a specific project or everything that is GNOME as something bad. All of you are doing great and you shouldn’t care at all about distro packaging problems.
Thank you. 