Not libraries:
Libraries have their own versioning scheme, since that’s tied to technical issues like API and ABI; this won’t change.
GNOME libraries should probably stop using even/odd versioning, though. But yeah, other than that this definitely does not apply to libraries.
So after 3.38, you could release either one of :
- 39 (truncate the major and start incrementing)
- 40 (next version would have been 3.40, then truncate major)
- 41 (as the 41st version of GNOME)
I’d also add this proposal:
- 42 (“YY × 2 + 0” for first release of 2021, “YY × 2 + 1” for second version of 2021.)
This means that as long as you release every 6 months:
• “M / 2” tells you which year it has been released
• “M modulo 2” tells you if it’s the first or the second release of the year (0 or 1 with 0-based index), so even is first, odd is second.
This scheme contains an indirect time reference for people who care, while avoiding the whole discussion of a YY.m scheme around “is 20.1 a new major release or just a minor update of 20.0 ?”, and the ambiguity of the Ubuntu scheme (“Ubuntu 18” being sometimes used without knowing if that means 18.04 or 18.10). The “hitchhiker’s guide to the galaxy” reference is just a nice bonus, also helping some people remember when the scheme changed.
Hope this helps.
3 Likes
I’ve not read all the thread, but here is what I think:
- I think some app developers (like me) would love to have a more rapid release schedule, for example doing a new stable release of the app every 3 months or every 2 months, or when it’s ready. With the desktop (gnome-shell etc) still having a 6-months release cadence. How would the numbering scheme work out in that case?
- Some apps install a pkg-config file for plugins. So with
alpha,betaandrcin the version number it would not work well for version checking. - How to “sell” that an alpha version is actually better than the previous stable version, when that is the case? It happens when doing lots of code refactorings, bug fixes etc in an old codebase that didn’t age well. Backporting the bug fixes is difficult because of all the refactorings. This point is related to the first point.
It’s a good point tbh… maybe not a blocker, but it’s certainly going to be pretty awkward. Considering also the added complexity to downstream version numbers, maybe we ought to rethink our approach to development releases.
We can indicate development releases using version numbers without having to use even/odd versioning, though. E.g. we could say that everything n.90 and above is a devel release for the n+1 stable release, like GTK is doing for GTK 4. I’m not sure if that’s really a good idea, but it’s a strawman starting point for discussion.
Non-core apps can follow whatever versioning scheme they want: no need to use GNOME versioning. But I’m not sure if it’s a good idea for core apps like gedit or devhelp to do their own thing with versioning. That probably merits further discussion.
and spend about 6 months dealing with the fall out - let’s not put the engagement people having to do extra work since ultimately it will fall on our shoulders to manage that and that’s a lot of emotional energy spent.
Why is your pkg-config file being matched to an “alpha”/“beta”/“rc” component?
Additionally, it’s not necessary to have that information in the programming interface; this versioning scheme is meant for user-facing components.
If your application is adding functionality that you need to discover at configure/build time, you can add numbers, if you feel more comfortable with them.
I’m ok with going to GNOME 40 as it will avoid confusion with GNOME 4.
Does anyone know if Ubuntu/Fedora/openSuse have scripts that key off the version ?
How does this affect git branches and other release methodologies? I think we have some automation there as well? I’m asking only to understand what gets affected when we move to the scheme so that we allot the right time for the switch over.
Finally - when we do finally work this scheme out - I would like to start engaging with the press and explain it directly to them so that we don’t get any confusion regardless.
Not aware of those distros specifically but:
- NixOS has a script for finding latest version of GNOME software defaulting to odd-unstable policy. That is easy to modify when the change is pushed.
- Repology has ignore lists that are per project so much harder to change.
Just so that we’re clear: GNOME is not responsible for fixing downstream scripts or version detection. That’s what distributions are for.
What we must do is:
- adopt a versioning scheme
- communicate clearly what versioning scheme we chose
- leave enough time to downstream packagers to cope with the new versioning scheme, according to their own schedule and development process
In order to minimise the complexity and improve the communication, the versioning scheme should be consistent, and not have a bunch of caveats.
In order to maximise the time needed to fix downstram scripts and packaging rules, we should likely defer the change to the beginning of the next cycle. This way, everyone will have enough time to deal with the change.
Additionally, we have to take into account that there will be problems, bugs, and delays. This is inevitable. We should have a process in place to deal with them when the occur, not before.
Let’s not try and architect a grand scheme that will be perfect from day one; I can assure you that it won’t be.
2 Likes
Since we branch only on stable releases, instead of gnome-X.Y we’ll have gnome-X.
Releases are specified from tags, so instead of X.Y.Z we’ll have X.Y or X.(alpha|beta|rc).
Our release recipes still use URLs to tarballs and checksums, so it’s just a different name.
Ignoring libraries (which would not change the pattern), it’s actually easier to detect a development release with the new scheme: if the application version matches .(alpha|beta|rc)[0-9], then it’s a development release.
1 Like
Yes - that’s exactly what I wanted to hear. I agree that it is their responsibility - but we should do our due diligence and provide clear messaging and a timeline that will allow them to make the required changes since after all - delays there means delay of getting GNOME to our users so it is in our interest to make the transition as smooth as possible.
I would add that we should be available to answer questions as needed by giving them an avenue to chat with - and that could simply be “go to #gnome-hackers and ask your questions there” - it just needs to be documented.
1 Like
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 Archive:Tools/RPM/VersionComparison - Fedora Project Wiki, except fc4 is considered older than fc.4.
It seems its behavior did match RPM exactly until this commit was made: Explore groups · GitLab
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.