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