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.
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.
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.
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.
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”.
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 .
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:
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.
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.
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.
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.
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.
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:
it might make it clearer this is the year of release, hopefully avoiding the “Ubuntu 18” example @mcatanzaro and @alicem were talking about;
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”, … ?
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.
