According to Wikipedia, 3.38 will be the 40th GNOME release. GNOME 40!
1 Like
This is one unavoidable perception, unless we increment the major version every six months, and reserve the minor version for monthly releases (which will go up to 12/13).
While the tick/tock cadence is tempting from a user perspective, it also has its share of problems:
- we rarely have features that require just one cycle of stabilisation
- volunteer work is not fungible, which means we don’t get to tell people “no feature for this cycle”
- it would nudge downstreams to start shipping every other GNOME release
which is why I tried to keep it out of scope for this proposal.
Yeah, I don’t think tick/tock will work for GNOME, and date-based really does imply tick/tock, which is what I’m trying to avoid by encouraging alternative proposals.
It’s actually not a wild idea. We could do that.
That will always happen for as long as we have two releases per year. I mean: it’s not like this is the first time somebody proposed that release X introduces new features, and release X+1 stabilises them.
I think we might need to address perceptions as FAQ questions when we announce the versioning scheme. I do not have an insight on what community or public perception will be. But I do like the fact that it is easily parseable.
I did get the impression of a tick-tock from the versioning scheme - so we will need to be careful not to give that impression that we’re moving to such a model.
To avoid the tick/tock cadence and the “I don’t know how years work/what years are” objection, let’s drop the year and the minor version, then, and move towards a simpler scheme:
New versioning scheme
GNOME will publish two major versions per year; each version is going to be supported for no less than 12 months.
The version scheme is: M.N
where:
Mis a monotonically increasing number, starting at 4, and incremented with every new six months cycleNis either one of these tokens:- one of
alpha,beta, orrc, followed by a monotonically increasing number, for each development release - a monotonically number, starting from 0; the number is increased by 1 for every stable release
- one of
Examples
Assuming that 3.38 (September 2020) is the last release with the old versioning scheme:
4.alpha0: the first release of the first development cycle of 2021; equivalent to 3.39.0 in the old versioning scheme4.0: the first stable release of the first development cycle of 2021; equivalent to 3.40.0 in the old versioning scheme5.beta2: the second beta release of the second development cycle of GNOME for the year 2021; equivalent to 3.41.91, in the old versioning scheme7.0: the first stable release of the second development cycle of GNOME for the year 2022; equivalent to 3.44.0, in the old versioning scheme8.9: the tenth stable release of the first development cycle of GNOME for the year 2023; equivalent to 3.46.9 in the old versioning scheme
2 Likes
Wouldn’t the year prefix help match GNOME with flatpak SDKs? I have noticed that they have been named following a date format like “19.08” or “20.08beta”.
Can’t we avoid the tick/tock confusion if we simply stick to year.month[token]?
This is the compromise scheme between people that don’t like years/months and everyone else.
We are on completely separate cadences and release schedules. The fdo Flatpak run times are released yearly, so they don’t have any tick/tock issue to begin with.
2 Likes
+1 from me
We might also want to consider dropping half our development releases and simplifying to just one alpha, one beta (equivalent to .90), one rc (equivalent to .92).
So, we’re going with the “one bourbon, one scotch, and one beer” release methodology? 
1 Like
In my opinion, this an even finer proposal 
A new GNOME release may bring any number of user interface changes, or no changes. The new proposal makes the reality clear that every time you switch to a later version of GNOME, it might bring you some exciting and/or disruptive changes.
volunteer work is not fungible, which means we don’t get to tell people “no feature for this cycle”
This succinctly explains why GNOME can’t/shouldn’t make a more complicated promise than the above with regards to when we introduce changes and new features.
For some context, this is where Debian ended up. For ages there was a mix of 2.x, followed by some 3.x, and it was never clear when 4.0 should be released. We moved to simply incrementing the number by 1 each time there’s a main release, as otherwise people read into the number promises that simply weren’t true. I’d personally support the scheme of M.N above.
3 Likes
I don’t think we should put a GNOME 4.0 release out there. Because expectations.
1 Like
Should we skip to 5? Directly to 40?
I don’t think it’s a big deal because if we release GNOME 4 in September and then GNOME 5 in March, it should be very clear that GNOME versions are not related to GTK versions.
But I’m also totally fine with skipping ahead to GNOME 40. That makes sense too. If systemd can skip 200 versions, we can probably skip a few dozen.
I’m not a member of Gnome foundation/moderators so my opinion can be safely ignored. I only belongs to the commonality which use Gnome on daily basis.
I would expect/like that the versioning scheme to convey/imply two informations “when” was the software released and if there would be major features/breaking changes shipped.
I like the idea that the year of the release would be included in the versioning number.
I like skipping to 40 as well, avoids the confusion on why 4 was skipped.
Is that compatible with the versioning used in the majority of the package managers that ship GNOME? I’m pretty sure that alpha/beta/rc is going to be sorted after digits. If we need to preface them with ‘0’, then it’d be a shame to switch from one slightly opaque scheme to another one that’s slightly opaque.
“GNOME 40” sounds fine to me, though I think we don’t want to change the version midway through the 3.37 development cycle. We should release 3.38, and then move to the new version scheme at the beginning of what would be 3.39, so we can release 40.alpha1.
I don’t know; considering the wide-ranging bestiary of package managers, I think the responsibility for properly sorting alpha/beta/rc releases is really on downstreams.
Debian’s rules for upstream version numbers would cover the alpha/beta/rc versions, since they allow for dot-separated alphanumeric values.
The rules for Fedora would also cover alpha/beta/rc, as alpha sorts before beta, which sorts before rc.
I guess if downstream needs additional rules, they can also amend the package version.
In general, this proposal deals with user-facing version numbers—the version displayed in the Settings → About panel, and the About dialog for applications. Package versions are less interesting, since you can’t really install two versions of GNOME at the same time, so downstream packagers can conceivably keep calling their packages “gnome-something”.