Straw man proposal: Changing the GNOME versioning scheme

Community
,
1

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.

Proposal

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.

21 Likes
2

Interesting idea. For me, as end user of GNOME desktop, it makes sense to place year in version number. It seems to be more readable. This kind of version number is easier to place in timeline, similarly to Ubuntu’s versioning system.

But, I think that, if this kind of change will happen, all core GNOME apps (like Nautilus, gedit) should follow the same versioning scheme; for consistency.

2 Likes
3

Hi, personally I think its just something that doesnt change anything at all, except the numbering. Quality will still remain the same.

4

I always liked that Ubuntu used truncated years for major version numbers. When I get a bug report or support request from an Ubuntu user with the distro version number, I immediately have a sense of how old their software is, even without knowing the specifics of Ubuntu’s release cycle.

As a developer of a mature and slow-moving part of the desktop, I’m realistically on a one-year release cycle. The jump from 20.0 to 20.1 feels like it should be smaller than the jump from 20.1 to 21.0. Sure the actual numbers are largely irrelevant as long as they’re monotonically increasing, but I think others would have that same feeling.

Short version: I’m super enthusiastically in favor of the year-based major version number. I’m kind of wishy-washy on the minor version number scheme. I feel like there’s probably something better, but I don’t have a suggestion, and I don’t want to add stop energy.

1 Like
5

Worthy brainstorming; I’d also like to move away from the current versioning scheme. A couple issues with your suggestion:

  • The numbering would make more sense if we make our releases tick-tock (like yelp), a major release and a minor release. Otherwise it’s really weird to have 20.1 halfway between 20.0 and 21.0, rather than a minor improvement over 20.0. Semantically, it’s just confusing otherwise. But I don’t think we want to do tick-tock.
  • If we do date-based, the far more familiar convention would be 20.03/20.09, parallel to Ubuntu, buildroot, freedesktop-sdk, etc. rather than using 20.0/20.1.
  • Users who don’t understand the versioning scheme will get confused and drop later numbers. E.g. many software installation instructions or minimum system requirements reference “Ubuntu 16” or “Ubuntu 18” because they don’t realize 18.04 and 18.10 are two different major releases. I’ve even seen experienced community members refer to “Ubuntu 18” when they presumably mean 18.04. I won’t be keen to see this happening with GNOME versions; people will report bugs against “GNOME 21” when we really need to know 21.0 vs. 21.1 (or 21.03 vs. 21.09 if we use month numbers).
5 Likes
6

Indeed. I really appreciate the Ubuntu versioning convention.

7

So, a few replies:

It’s not strictly necessary; generally speaking, every project inside GNOME isn’t required to match the GNOME version number. Changing the GNOME version number to something simpler may also be used to nudge applications to follow their own versioning scheme—with more releases, more often; or even with fewer releases.

I chose tick-tock .0/.1 numbers because, unlike Ubuntu releasing on even months, we tend to release on odd months. Switching to a different minor versioning scheme would avoid any connection with the even/odd pattern we used until now.

I don’t have any firsthand experience of that, so I’ll trust you. Nevertheless, we do need a minor version. We could do .0/.5, if we wanted to be cute about it, to signal that we’re halfway through the YY development cycle.

1 Like
8

If the actual minor number truly doesn’t matter, we could do away with point-oh entirely, use 20.2 and 20.4 for the stable releases, and use 20.1 and 20.3 for the development series. But maybe point-oh is just too ingrained.

9

I dislike the existing version scheme, purely based on the fact that it is really confusing. On that basis, this seems like a good proposal.

That said, some thoughts…

I too share the concern about the proposal being suggestive of a tick-tock schedule (fine if we do operate on a tick-tock basis, but it would be misleading if we don’t).

While date-based schemas are cool and useful once you understand them, they can actually be pretty confusing until you do. Way back, I remember being somewhat baffled as to why there was a Ubuntu 14.04 and no 14.0. From this perspective, sequential numbers for equivalent releases have something going for them: they’re simple, and easy for everyone to understand without having to have the schema explained first.

There is possibly a debate to be had regarding the semantics of major version bumps. Clearly it is possible to make major technical changes without them, but what matters is what the user sees and experiences, and a major version number change can be used to indicate and give license to larger UX changes, should they be desired. You could make major changes without the version bump, of course; I guess it’s just a question of how surprising it might be.

1 Like
10

I can confirm what @mcatanzaro said. Happens a lot in #newcomers, for example:

Screenshot%20from%202019-11-05%2013-01-21
Screenshot%20from%202019-11-05%2013-01-21846×1650 120 KB

1 Like
11

Maybe we should, considering that we don’t want to give up the 6 months release cycle while at the same time trying to stretch the development time of features over more than the 3-4 months allotted to them by that cycle. Anyway, that’s related but not strictly part of this proposal.

I’m pretty sure that people used to GNOME 3.0 would be surprised by the current state of GNOME 3.32:

  • no more message tray
  • compound system menu
  • integrated clock/calendar/notifications
  • header bars, hamburger menus

The only thing that reverted back is the lack of an app menu in many cases. :wink:

More importantly, at this point, is that I’d like to question the need to do a major, non-incremental UX change. I mean: we can still do them, but we’d have to communicate them better than “number goes up” anyway. From a platform perspective, the main reason why we decided to go for the new GTK release schedule is that we want to introduce the concept of a constantly developed GTK—going from 3, to 4, to 5, and further on—without necessarily thinking that major API bumps are to be feared. GTK, sadly, needs an incremental major version because of restrictions on how shared libraries must work; as far as I’m concerned, though, we could call GTK4 “GTK 2020”, and call GTK5 “GTK 2025”.

1 Like
12

I see that one of the proposals was a system like Ubuntu’s releases with . of release (To be honest that’s the first time I have heard that is what these numbers mean) with the main drawback being that people don’t understand that the part after the dot is still part part of the version number.

What I find interesting is that I didn’t notice a suggestion to use something similar to Windows 10’s feature updates release version number. For example, GNOME version 1903 (which would be GNOME 3.32). Would be a bit harder to misname compared to GNOME 19.03 for those users who might ignore the minor number. It would be a way bigger number though, and not much better than simply having a GNOME 2019.03 .

13

Another option would be a Fedora-ish versioning. New features get a new major version, bugfixes get a n.1. Development versions would be alphas, then betas and RCs. For example:

Gnome 3.38 -> Gnome 4
Gnome 3.38.1 -> Gnome 4.1
Gnome 3.39 -> Gnome 5 Alpha (5 alpha-1, 5 alpha-2, etc.)
Gnome 3.40 -> Gnome 5

I think this would make them easier to identify for users, since each release has a distinct number and higher == newer. And future development versions are separated from current stable from the get-go.

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

16

The problem is not “number goes up”: it’s giving context to what that number means. I have no way, without looking at a website, to know if Fedora 31 is the new stable release, nor I have any idea when Fedora 29 was released, except that it was released earlier than Fedora 30 and later than Fedora 28. There would be no difference between this schema and GNOME’s current one, which is the whole point of this proposal.

1 Like
17

You always need some context. You know Ubuntu 19.10 is the latest stable version because you know Ubuntu releases twice a year, with the latest one in October. I wonder hoy many users might be running 19.04 thinking “Ubuntu 19” is the latest version. On the other hand once a user learns there are two major releases per year it’s not very hard to calculate how old it is: 31 - 29 = 2, divided by 2 releases per year, it’s 1 year.

I disagree. With the current system you have to know a somewhat random number (3.36) is the latest one, you also have to know 3.37 is the development version and the stable version that follows is 3.38. Forget about calculating how old a previous version is.

With the Fedora (or Chrome/Firefox) system you know every major change is a stable release, and unstable releases are suffixed with alpha/beta. Most users are already familiar with this scheme.

18

On the other hand once a user learns there are two major releases per year it’s not very hard to calculate how old it is: 31 - 29 = 2, divided by 2 releases per year, it’s 1 year.

I’ve been running fedora for year and I still have no idea how old a fedora 24 is or what gnome version it shipped. Nor can I think calculate how old Firefox 68 or 73 are off the top of my head. How important that is, is a different matter, but I don’t think its simple to figure out the release date of these schemes without looking for the release announcement date.

19

I only used Fedora as an example for Gnome itself, not as a Fedora+Gnome.
Still, using Fedora you would get 2 updates per year. Knowing that you can do (31-24)/2= 3.5 years.
iOS would be another example. They have been bumping the major version every year since 1.0, and it’s easy to figure out how old a version is.

20

I really like date-based versions in general, and also think this would make more sense for an umbrella project like GNOME. (whether the individual components forming GNOME should also switch is an entirely different conversation IMHO and there is no reason to tie the two together)

However, I feel I should mention that using the full year would be a much better idea:

  1. it might make it clearer this is the year of release, hopefully avoiding the “Ubuntu 18” example @mcatanzaro and @alicem were talking about;

  2. people are going to write scripts and tools which assume the length of the first segment of the version string, and will be faced with a Y3K bug; using the full year makes it more likely people will use standard date parsing mechanisms which will be better immune to this;

In fact, why not go all the way and use a YYYY.MM (or even YYYY-MM scheme, but I bet lots of tools don’t expect hyphens in versions), with point releases?

Would the “Ubuntu 18” problem happen with versions like “2020.03.0”, “2020.03.1”, “2020.03.2”, … “2020.09.0”, “2020.09.1”, … ?