This is a straw man proposal meant to jump start a conversation about changing the versioning scheme of GNOME; it’s meant to be iterated upon, and discussed, and may be even potentially dismissed.
This is the Third Age of GNOME, after the 1.x and 2.x development cycles; hopefully, we kind of learned the lesson that massive changes in the underlying platform do not necessarily equate to changes in the UX, as well as the vice versa.
Back when we released GTK3, causing the various ripples in the stack that led to other major API bumps, we also took the chance to do a massive UX change in the form of GNOME Shell. These days, we have GTK4 in progress, and we’re going to need major API bumps in many libraries, but thanks to the work done in the previous cycle, we consolidated a lot of functionality into the core platform itself, which means fewer disruptions. Additionally, we also have Flatpak and Snap, which allow application developers to be more conservative and move at their own pace. Releasing GTK4 does not imply a massive change in the project’s direction.
Similarly, UX and DX design are proceeding incrementally, constrained by the available resources and by the 6 months development cycle; this is good, as it leads to iterations over all new designs, and additional testing.
We have reached a minor version number in GNOME higher than the last 2.x release, and the trend seems well on its way to get us to even higher numbers—and just like GNOME 2.30 was fairly different from GNOME 2.0, what a person installing GNOME 3.34 gets is very different than what they used to see when installing GNOME 3.0.
Maybe it’s time to retire the major/minor version number as a signifier of the current GNOME UX.
Replace the 3.x version moniker with the year of the release, followed by an incremental number to separate the March and September releases.
Let’s say that GNOME 3.38 (scheduled for September 2020) is the first release of the New Versioning Scheme; we could adopt it as:
- GNOME 20.1 (September 2020)
- GNOME 21.0 (March 2021)
- GNOME 21.1 (September 2021)
The stable cycle (12/13 monthly run time releases, as per release-team plan) would be:
- GNOME 20.1.0, 20.1.1, 20.1.2, 20.1.3, …
- GNOME 21.0.0, 21.0.1, 21.0.2, 21.0.3, …
The main issue is the version numbering for the development cycles; we currently use an even/odd minor version, which would not work withing the new scheme. This means we need to figure out a new versioning scheme that communicates “this is the development channel of GNOME”. One option would be to append a very high number at the end of the previous version, e.g.
- GNOME 20.0.90, 20.0.91, 20.0.92, 20.0.93, … → 20.1.0
- GNOME 20.1.90, 20.1.92, 20.1.92, 20.1.93, … → 21.0.0
We’re not going to do 90 releases off a stable branch, so we’re not going to conflict there.
One pro would communicate that the next release is a continuation of the previous stable release; a con would be that it conflicts with the existing beta numbering scheme, though since we’re literally changing the versioning scheme it may not be a problem.
Changes in modules
The change in versioning is mostly meant for GNOME as a project. The only module that would need to reflect the new version is gnome-desktop, as that’s where the user visible version number is stored.
Another change would need to be applied to gnome-build-meta which is the module used to build the release and the Flatpak run times.
If GNOME application maintainers wish to follow the same versioning scheme as GNOME, they are free to do so. They should also be free to decide their own versioning scheme, as they may release more often, or less often, than GNOME itself.
A side note on version numbers
Version numbers don’t mean anything by themselves. The only thing they communicate is “number goes up when newer, down when older”, i.e. they tell you where you are with regards of what came before, and what will come after. Outside of the specific context in which they are used within a project, they have little to no meaning.
The problem is that their meaning only fully materialises when placed in context. If Alice says she’s running GNOME 3.34 and Bob says he’s running GNOME 3.30, then Alice and Bob must come to the shared understanding that GNOME has 6 months release cycles, and skips odd minor version numbers, in order to realise that the version of GNOME Bob is using is a year older than the version of GNOME used by Alice; on top of that, the version number still doesn’t communicate when the release was made, unless both Alice and Bob check which version of GNOME is the latest, and work their way backwards.
By using an existing shared version counter—like the year in the Gregorian calendar—we remove the need to create additional shared knowledge (two releases per year, even/odd versioning, latest version) to determine where in the timeline of GNOME releases Alice and Bob are, both with respect to each other, and with respect to the project itself.