Yes, that seems very common and well-understood. Our downstreams should be able to deal with it. Upstream, our black magic release scripts are going to need some serious help to handle this convention, but let’s assume we can figure out how to update those should we decide to change our versioning.
I don’t think our downstreams are what we should be worried about here, both date based and semver schemes are already used by a flood of other projects and downstreams should be able to handle them already.
I think its better to focus on what the number means and how its understood by the wider public.
1 Like
So, it is time to draw up a formal proposal.
Summary
- the existing versioning scheme—
MAJOR.MINOR.MICRO—is confusing, especially now that we’ve stabilised around the “3” major version and we’ve constantly incremented the minor one - the even/odd split is unnecessary and does not communicate instability any more, given that very few users are even exposed to development releases of GNOME itself, and those that do, already know it
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: YY.N.M
where:
-
YYare the last two digits of the year in the Gregorian calendar, e.g.21for 2021; the number is incremented only when the first release of the year is made -
Nis either 0 or 1, depending on the six months cycle -
Mis either one of:- 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 release
- one of
Examples
-
21.0.alpha0: the first development release of the first six months cycle of GNOME for the year 2021; equivalent to 3.39.0 in the old versioning scheme -
22.1.beta2: the second beta release of the second six months cycle of GNOME for the year 2022; equivalent to 3.41.91, in the old versioning scheme -
23.1.0: the first stable release of the second six months cycle of GNOME for the year 2023; equivalent to 3.44.0, in the old versioning scheme -
24.0.9: the tenth stable release of the first six months cycle of GNOME for the year 2024; equivalent to 3.46.9 in the old versioning scheme
Recommendations
The GNOME core applications (as defined by the release team) are strongly encouraged to follow the same versioning scheme as the GNOME project.
The applications in the GNOME Circle group are free to follow their own versioning scheme, as well as cadence.
3 Likes
With my maintainer hat on (of future-Circle apps), it would be great to ensure to agree on how the stable branches will be named after that change (currently, it’s usually “gnome-3-XX”); is “gnome-21-0” and “gnome-21-1” good enough for everyone, for talking about the two releases of year 2021?
My personal preference would be for versioned branching to follow the same version of the SDK you’re targeting; this means that if you’re releasing your application based on org.gnome.Platform//21.0, your branch should be gnome-21-0.
I’m constantly struggling to remember version numbers and I agree that the versioning has become excessively cryptic. This looks simpler and easier to understand than the current proposal, so I’m generally positive.
As someone who hasn’t closely followed the discussion, it would be useful to have a brief summary of the options and why this particular schema was selected.
The only other option that was proposed was to bump the major version to 4, reset the minor version to 0, and then increment the minor version by 1 every 6 months; there was no concrete proposal for when to increment the major version.
Basically, every proposal has to factor in these requirements:
- the major version is not important any more, and it’s just an incremental number
- we have two, 6 months cycles
- each six months cycle has a development phase, with alpha, beta, and release candidate releases
- each six months cycle releases a platform that will be updated for 12 months
If we release 4.0 in March, and 4.1 in September, then we have to choices for the March release:
- release 4.2, which means that the major version is relevant because that’s how people consider version numbers, and then we’re back to the current situation
- release 5.0, which means that the major version is just an incremental number, at which point it could be anything; and since we’re using time to determine the schedule, might as well use time to determine the version
Another proposal: we drop the minor version, and we pull a web browser/Fedora, incrementing the major version every six months: GNOME 4, GNOME 5, GNOME 6, … Each version will have:
- a development phase: 4.alpha1, …, 4.beta1, …, 4.rc1, …
- a stable phase: 4.0, 4.1, … 4.12
I’m still hoping to avoid date-based…
Another proposal: we drop the minor version, and we pull a web browser/Fedora, incrementing the major version every six months: GNOME 4, GNOME 5, GNOME 6, … Each version will have:
- a development phase: 4.alpha1, …, 4.beta1, …, 4.rc1, …
- a stable phase: 4.0, 4.1, … 4.12
Variation on this: we pull a Windows 10 and just stay GNOME 3 indefinitely. But we drop even/odd versioning going forward, and just release 3.40, 3.41, 3.42, 3.43, etc.
Another variation: we pull a Linux kernel and increment the major version at entirely arbitrary points, say every 5 years.
You made it painfully obvious, but outside the “some people don’t understand Ubuntu versions” objection I haven’t heard a single justification for that.
Yes, people don’t understand the Ubuntu versions; Ubuntu has a lot of mixed messaging about their versions—is it name based? Is it numeric?—and we would not have that problem to begin with because we only ever use versions to describe our platform.
No, that defeats the purpose of the whole exercise, and does not provide us with a clean break with the existing versioning scheme.
Random increments are not any less confusing.
I’d be okay with using a single component, monotonically increasing version number every release, by the way.
The version scheme is:
YY.N.M
This is a fine proposal. It seems inherent in this numbering scheme that the 21.0 release would bring major changes while the 21.1 release would bring incremental improvements.
Indeed, this implies a tick-tock release scheme which isn’t true. Would have been less of an issue if we had 3-4 releases in a year though. I don’t think though that its likely we will end up shortening our release cycle anytime soon as it would mean we would have to support more releases in a year.
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).