Straw man proposal: Changing the GNOME versioning scheme

I expect we’re going to publish a proper explanation on Discourse and send an email to distributor-list. If packagers have questions, the distributors-list is the appropriate venue; if random people have questions, Discourse is probably the best place. Sending people to IRC isn’t going to be very useful, especially for long form questions and answers.

OK - I think that seems fairly clear now.

As a rep of the engagement team - once we’ve hashed this out - I will try to help facilitate some communications with the wide world - so that there are no mis-communications and we have a chance to review what we are going to communicate. We will also reach out to phoronix and others ahead of time so they get the accurate story from us and not whatever they deem to print.

For what it’s worth, evolution-data-server, evolution, evolution-ews and evolution-mapi are tightly connected together. Evolution version x.y.z requires evolution-data-server x.y.z, similarly evolution-ews and evolution-mapi both require evolution x.y.z and evolution-data-server x.y.z. Each has the same x.y.z version, thus it’s super simple to write such connections in the build/configure scripts.

Maybe it doesn’t matter, because eds is a library and evo is not a core application, thus they can do whatever they like to (with respect of the version number), if I’m not mistaken.

gedit installs a pkg-config file for gedit-plugins and third-party plugins. The version check is useful, to avoid trying to compile a plugin against the wrong version of the gedit application.

A little like Evolution, except that gedit is a core app.

To clarify, once again, the versioning scheme: when a new development cycle starts, we bump up the MAJOR version, just like today we go from 3.EVEN_MINOR to 3.ODD_MINOR. Additionally, the alpha release would be the equivalent of the 3.ODD_MINOR.3 release we do these days. There wouldn’t be multiple alpha releases—considering people skip most of them anyway. In other words:

  • 3.39.0 → [dropped]
  • 3.39.1 → [dropped]
  • 3.39.2 → [dropped]
  • 3.39.3 → 40.alpha
  • 3.39.90 → [dropped]
  • 3.39.91 → 40.beta
  • 3.39.92 → 40.rc
  • 3.40.0 → 40

Plugin developers can keep matching on the MAJOR version, since we’re going to increment it every six months. If you introduce new API during the development phase, they are still going to ask for >= $MAJOR if they need an API. If you’re worried about API additions between alpha and beta phases, I’d recommend not to do them as a general rule, given that beta is when we freeze things, and alpha would be the month before.

In any case, I just checked how pkg-config deals with this issue.

A pkg-config file with a Version: 40.alpha is perfectly valid, and it does work as expected: the --atleast-version=40.alpha will match, whereas 40.beta will not. Additionally, if you change the version to 40.2 and use --atleast-version=40.alpha, the result will be successful.

This is with pkgconf, which has replace pkg-config in many places; I’m sure we can fix pkg-config to take into account alphabetic identifiers and sort them appropriately.

Meson’s version_compare() also works, by comparing chunks separately. We can probably fix things there as well, as I’m sure other projects will have to deal with this.

My personal opinion is that a jump from 3 to 40 does not seem right. I think that version numbers should be at least somewhat continuous and predictable and skipping large amounts of versions does not feel right to me. Even a jump from 3 to 5 would probably need an explanation on why 4 was skipped. Going to a YEAR.MONTH scheme is a different thing, but having such versions in individual component version also does not seem right to me, that’s more of a branding thing for umbrella releases (see my comment below).

In general, I also think that non-technical people probably do not pay attention to the version and thus have no understanding if they are even running GNOME 2 or GNOME 3, this certainly applies to some people for whom I maintain their OS. But developers and administrators do pay attention to the version and could be confused if there are sudden large jumps in the version number. I know this is highly subjective though.

I personally prefer to have small increments in versions such as from 3 to 4. I also think, the decision for a version 4 SHOULD be independent from when ever a GTK4 is released. If you like to adjust the versioning scheme nevertheless, may I suggest to take a look at the Spring Framework which recently has revised its versioning scheme. They published a blog post on (https://spring.io/blog/2020/04/30/updates-to-spring-versions), maybe it can offer some inspiration. I personally like the idea of separating the version of the umbrella project (e.g. Spring) from the individual module versions (Spring Framework, Spring Boot). We could think about adopting a year.month like version for the GNOME umbrella release to be used as a general branding, but keep the classic semantic version scheme for the individual modules. So a GNOME 2020.10 (e.g. 2020, October) umbrella release could still ship with Gnome Shell 3.38. A note in the package description could state that 3.38 was part of the 2020.10 umbrella release train.

In apt/dpkg, 40.alpha1 compares as slightly newer than 40.0 (specification), so apt/dpkg distros like Debian would convert an upstream version 40.alpha1 into 40~alpha1 to make it sort the way you’d hope, because ~ sorts slightly lower than the empty string (which was implemented specifically for alpha, beta, rc and snapshot versions). This can be, and in practice is, automated: Python is a prominent example.

Other versioning and packaging systems either do the same as apt/dpkg (I think RPM has the same special handling for ~?), or have a special case for specific substrings like alpha (I think Arch Linux’s pacman does this?), or fail horribly and will need a workaround (for example versioning the proper release of GNOME 40.0 as 40.rel.0, if they consider rel to be newer than rc like dpkg does).

As a rule of thumb, I would say that the “big” package managers like apt/dpkg and RPM will have well-established ways to handle this versioning scheme, but more minor/minimal/obscure/NIH package managers are more likely to have trouble with it.

1 Like

Arch Linux’s Pacman’s libalpm calls the comparison function rpmvercmp and its behavior matches the examples at https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison, except fc4 is considered older than fc.4.

It seems its behavior did match RPM exactly until this commit was made: https://git.archlinux.org/pacman.git/commit/?id=30d978a966c1d2a619acc49f204e4da1e0010c83

Edit: The commit mentions that even before, the behavior did not match, as RPM considers 2.0a > 2.0 but pacman uses 2.0a < 2.0.

To clarify, this means the versioning scheme as presented in post 97 would not work as is, as 40.alpha > 40. Pacman wants 40alpha < 40 or 40.alpha < 40.0.

I think I wasn’t exceedingly clear when I said that I honestly don’t care about how downstreams package GNOME, so let me apologise for that, and I’ll attempt to clarify my position: I absolutely do not care what kind of contortions downstream packagers need to do when packaging GNOME. They are entirely free to change the version to match whatever requirement their particular packaging format has. Since everyone has its own interpretation of how version numbers are sorted, there is no way for upstream to pick one and be done with it, so it’s entirely pointless to try.

The “alpha”, “beta”, and “rc” monikers are for GNOME users, which means it’s something they will see if they open the “About” dialog of GNOME core applications, and the “About” panel in the GNOME system settings.

If Arch wants to use “40alpha”, Fedora wants “40.0alpha”, and Debian wants “40~alpha” when naming the packages, then they are absolutely free to do that.

Right - this approach is mostly fine, as long as it’s possible for the various distros to get versions that look vaguely like the upstream version number, and sort correctly in the distro’s package manager. This is a mixture of an upstream requirement (don’t have version numbering that is completely weird, like the 1.1 , 1.2 , 1.3 , 1 , 2.1 , 2.2 , 2 progression mentioned in Debian Policy), and a downstream requirement (package managers already need to be able to represent alpha/beta/rc versioning, otherwise they can’t package Python correctly).

The places where sorting matters more for upstream code are the places where upstream version numbers get compared in APIs that do not have the opportunity to substitute a downstream version, such as pkg-config and Meson.

2 Likes

Yes, we as the upstream have the absolute requirement of making the versioning scheme consistent and with no edge cases, and give enough time for downstream to adapt.

Indeed, and I’m happy to look at this and figure out how to fix issues that arise in those context.

I wasn’t originally planning on jumping into this discussion, but since it’s been going off the rails…

Here’s my feedback on the whole thing: this is silly!

I really don’t think we should fear going to 4.0. I would personally like to see us tick up to 4.0 when the GNOME core apps are all ported to GTK 4. There is no reason for people to assume that GNOME 4.0 is going to be as awful as GNOME 3.0 was. Weird schemes like calendar versioning only makes sense if you’re switching purely to a time-based release process, and arguably, a modified scheme similar to what the LibVirt project does might make more sense there. If we want to jump to 40 and count up from there, fine. I think it’s a bad idea, but fine.

For pre-release versions, I would definitely prefer to see relatively consistent numbering for alpha, beta, and release candidate stages. For example: X.Y.5Z for alpha, X.Y.7Z for beta, X.Y.9Z for release candidate. I’d really like the even/odd scheme that not even the Linux kernel uses anymore to go away, though…

For the folks who have been talking about decoupling GNOME 4.0 from having all the core apps moving to GTK 4, that’s nonsense. There are two advantages to doing it that way:

  • The GNOME platform libraries can break and churn in lockstep and release together as part of GNOME 4.0 built on the GTK4 foundation. There are plenty of warts throughout the foundational library stack in GNOME, and we should take the opportunity to make it better.
  • Being version 4.0 gives the opportunity for everyone to take a fresh look at GNOME, and maybe some people might actually like it when they hated it under GNOME 3.x. There’s evidence of this being successful with the release of Windows 7 to replace Windows Vista. The two releases are almost entirely the same, but 2009 was kinder to Windows NT 6.x than 2006 was.

But feel free to ignore me, I’m just a distro guy, and as some other folks said in here, you don’t care what I think…

RPM has had ~ for pre-release versions since RPM 4.101. We also have ^ for post-release sorting since RPM 4.152.

… which we arguably already have: a new version is released every 6 months

There is no reason for people to assume that GNOME 4.0 is going to be as awful as GNOME 3.0 was.

Spoken like a true engineer. But reason is not what goes into people’s assumptions…

Thanks for your valuable feedback.

1 Like

What are people using for the version after branching for 3.38?

I want to increment to make it clear mainline is past 3.38, but I don’t want to use 40.alpha since that hasn’t been released yet. 40.dev?

This is the strawman proposal; the actual announcement has an example.

The new version was announced, so we can close this topic to avoid any further confusion.