Please strictly follow Semantic Versioning 2.0.0.
Which means specifically: Once there is 4.0, no incompatible API changes must be made anymore.
Thanks for your consideration.
1 Like
GNOME as a project cannot follow semantic versioning because it contains more than libraries and exposes more than an API.
Libraries in the GNOME SDK already follow semantic versioning for their API.
Oh, my word yes. Well, maybe not exactly that. It would be worse.
What would happen there is, people would run away screaming and give up on the version numbers entirely, never being sure what version of a thing they’re using / discussing. Or they’d latch on to whatever codenames or other tags they could find, to assign a more memorable identity to the release. Because coding that pathological should be reserved for accountants and legislative clerks.
I mean, heck, the Ubuntu numbering is comparatively painless. (Though, as a couple of people pointed out, you’d be surprised how many people don’t realize it’s YY.MM, or how long it can take the people who do know that to pick up on it.) Nevertheless, you still get people talking about “Ubuntu Xenial” and “Ubuntu Bionic”, because lots of humans just seem to prefer things that have names, instead of numbers — despite the obvious deficiencies of a name-based system when it comes to cataloging. (Though the alphabetical order of the codenames does help mitigate some of those.)
All GNOME releases have names, matching the location of the last GUADEC (for fall releases) or GNOME.Asia (for spring releases). And yet people are using the numeric versions currently.
Not all of them; we haven’t use release names in ages and only started recently to refer to them in the press releases and in the release notes. Release names are pretty useless in basically all cases except for marketing purposes.
The only reason why Ubuntu uses release names and Ubuntu users know about them at all is because they inherited from Debian’s APT the fact that repositories use the release name instead of the version number; it’s a broken approach and even Debian is considering an alternative, so let’s not go down this path.
1 Like
Thanks for correction, I should have said “all recent”.
Even still…
-
‘3.34’, ‘3.36’, those release numbers aren’t so bad. (And in practice, really, you can drop the lead version, so the most recent release was GNOME 3 version 36. Effectively.) That’s both an easy to remember and easy to interpret progression. (Nobody other than the developers is even aware of the intervening development release numbering. So to the average user, GNOME simply has an every-other, even-numbered release scheme.)
-
The GNOME release code names don’t tell you anything about the actual release. It’s lovely to honor the GUADEC hosts, but again, nobody but the developers is even aware of GUADEC, so it’s meaningless to them.
The Ubuntu scheme, like Debian’s before it, is an alphabetical progression. That conveys nearly as much as a numbering scheme. Heck, we’re programmers, we especially have no trouble mapping the alphabet onto a linear numerical progression — it’s even part of our notation for any numerical base larger than 10.
So, armed with just a little bit of prior knowledge regarding the scheme, when you hear, say, the names Bionic, Disco, and Focal, you can infer quite a few things about those releases and the relationship between them.
- Bionic is oldest, Focal is newest.
- They’re each a year apart, because they release every 6 months.
- And if you’re aware that Bionic was a LTS release (or you know that Trusty and/or Xenial were, from which you can deduce Bionic), then you further know that Focal will be as well, since those come every four.
I don’t even know what country Gresik is in, I’m ashamed to say. Never heard of it before in my life.
Debian is not alphabetical though.
The latest version is Buster, which comes after Stretch, which comes after Jessie. 
You’re right, they use Toy Story names, which are about as informative as obscure conference host cities — though at least the Toy Story names are more familiar. …Not sure which I was thinking of.
(Mint uses names in alphabetical order, but that came from Ubuntu, not vice versa.)
1 Like
What would the version number look like 100 years from now?
If we’re still releasing GNOME 100 years from now, we can probably reconsider the versioning scheme.
4 Likes
What if we fudge it?
Without changing the release schedule, we could call the March release 21.04 and the September release 21.10.
This has several merits (of varying importance):
-
Stable releases still have even minor version numbers.
-
People who don’t realise they’re dates might call them “21.0” and “21.1”, which is no worse than the original proposal.
-
This format (with even minor numbers) is also used by Ubuntu, KDE’s applications, and (who could forget) the freedesktop flatpak runtime.
-
Ubuntu 21.04 would ship GNOME 21.04, Ubuntu 21.10 would ship GNOME 21.10, and so on.
-
If you realise they’re dates, you can tell (approximately) when each version was released just by looking. You can discover that GNOME releases happen every 6 months.
We can call the preceding unstable series 21.03.x and 21.09.x.
-
These are odd minor version numbers, which continues our existing pattern.
-
If you recognise “21.09” as a date, and it’s now May 2021, you know straight away that this is a future release.
The only drawback I can see is:
- It’s a slight fib.
But:
-
We look like we consistently ship ahead of schedule!
-
Some magazines future-date their issues — they publish the “April” issue in mid-March and the “October” issue in mid-September.
-
Not many distros ship our March releases before April, or our September releases before October. Even if they do, nobody gets hurt.
1 Like
To me semver makes a lot of sense, even if you can’t strictly stick to its stipulations around ABI, why not use something like semver for GNOME? It seems a consistent measure to me… for GNOME, as I use for documents etc, ‘ABI change’ can simply mean ‘breaking/more-breaking-than-usual change’, e.g. (perhaps) a shift to GTK 4, or the next fundamental UI overhaul (if there ever is one). If no such ‘breaking’ changes arive, just stick with 3.x, doesn’t matter how big the number gets, the number will get huge if you increase the first number also (see how big the numbers are getting with Firefox and Chromium!) Maybe in 2100 there’ll be some breaking change, you can jump to GNOME 4.0 then! 
If you wanted, you could go even more for semver by taking its suggestions for pre-release versions, so, given GNOME 3.37.1 is already out, let’s say the 3.39/3.40 is the cycle that switches to semver:
old version number → new version number
3.39.1 → 3.39-alpha
3.39.2 → 3.39-alpha.1
3.39.3 → 3.39-alpha.2
3.39.90 → 3.39-beta
3.39.91 → 3.39-beta.1
3.39.92 → 3.39-rc
3.40.0 → 3.39.0
(see below, irrelevant as I haven’t yet read the whole thread in full)
Semver is pointless drivel as a general rule—it’s just “numbers go up”, which, well: thank you very much, I know how numbers work. Semver does not tell you anything about stability guarantees, or being able to upgrade, that’s the devel/stable release channel’s job, not the version’s. Semver is Hungarian notation for version numbers.
On top of that, it’s pointless to use semver for a project made of other projects, because it doesn’t tell you anything about the contents of the project; it doesn’t tell you that an application shipped with GNOME added a command line argument, or that there’s a new feature, or that a button has a new label. It doesn’t tell you that there have been bug fixes, or that they resulted in changed in the documentation or in the user visible strings.
Unless, of course:
- GNOME bumped the micro version every time a single component did a bug fix
- GNOME bumped the minor version every time a single component added a new feature
- GNOME bumped the major version every time a single component changed an existing UI element
Please, read the whole thread, especially the bits in which I specifically outline that major project changes are not necessarily tied to major version changes any more:
or:
or:
1 Like
I really like the fudged version scheme, it has all the benefits of the original proposal, plus (rephrasing):
- being able to figure out the date of release
- keeping minor version numbers even
- the version will seem more up to date for distributions such as Fedora and Ubuntu
- removing pressure from packagers of rolling release distributions, as the version will feel like it has yet to be fully released.
Fun fact: bumping the major version to 20 or beyond also avoids Tetraphobia (fear of 4, East Asian) or Triskaidekaphobia (fear of 13, Western).
1 Like
Whatever scheme is chosen, I wish the odd-even distinction would be abandoned and prerelease versions included “alpha”, “beta” or “rc” somewhere. Our packages at Arch Linux regularly get flagged out-of-date by clueless users.
1 Like
Yeah let’s get rid of even-odd releases, it’s an archaic convention only followed by GNOME. So let’s say we pick some future version of GNOME to be 4.0 and begin our new numbering scheme. Then we could do:
- 4.0
- 4.1
- 4.2
- 4.3
- And so forth
Very simple. Just 4 point something. The version number goes up by .1 every six months, instead of .2. Instead of odd-numbered development releases, we’d just have 4.0alpha, 4.0beta (equivalent to our .90 releases), and 4.0rc (equivalent to our .92 releases).
Alternative: something similar to Emmanuele’s date-based versioning proposal, if we want to go with date-based versioning. I’ve never been a huge fan of that, especially for consumer-facing version numbers, but it would be nicer than the even-odd we have now.
I didn’t want to open that particular can of worms, since it ends up hitting things like project cadence, and release timelines, but I do tend to agree that even/odd served us well in the past but simply doesn’t any more; very, very few people can even run an odd version these days, so nobody really cares about them outside of downstream distributors, just like nobody cares about even/odd versions in the Linux kernel.
I’d still prefer a time-based versioning scheme to go along our time-based release process, mostly because if we stop using major versions to indicate major changes in the platform then we’d have to start incrementing the major version according to some other metric, in which case we might as well use a concept that is already monotonically increasing whether we like it or not.
It’s usually hard to communicate what those mean, even to tech savvy users; people at large may understand beta because of a bunch of web services—though even those have started to say that they are in “permanent beta”.
The “release candidate” moniker can also be fairly contentious—especially once you drop the even/odd policy; is 4.2.0-rc1 the first release candidate towards 4.2.0 or the first release candidate in the 4.2 cycle towards 4.3.0? On top of that, 4.2.0-rc1 as the first release candidate towards the 4.2.0 release might end up messing the version comparison mechanism in various packaging tools.
You could have “alpha”, “beta”, and “release candidate” in the user visible version, of course.
4.2.0-rc1 (or 4.2.0rc1 by my preference) would be a release candidate towards 4.2.0. I don’t know of any projects who would make this a candidate towards 4.3.0 or 4.2.1, especially since you can’t distinguish between these cases.
AFAI am aware, this kind of versioning is common enough that all downstream distributors should be able to deal with it.