Frustations of a distro-packager with the versioning scheme of GNOME projects

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.

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).


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


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


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. :blush:


Emmanuele very recently typed up a PSA: On version schemes for GNOME components.

If that had been followed, that would have avoided these problems. The tracker versions should have been 3.4.rc and 3.4.0, not 3.4.0.rc and 3.4.0. The adwaita-icon-theme versions should have been 43.rc and 43.0, not 43.rc and 43.

The same happened with libshumate which had a 1.0.0.beta version before the final 1.0.0 version. The 1.0.0 version doesn’t pass a dependency check like shumate >= 1.0.0.beta. The version mishap was worked around by doing a 1.0.1 version.

I guess the same needs to happen with tracker and adwaita-icon-theme.

@ebassi I guess your PSA can do with some more exposure to developers and maintainers.


Yes, my PSA was written precisely because we’ve had a few projects going in their own direction and we (as the release team) discovered it far too late.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.