Hi all;
This email is cross-posted to Discourse:
https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
Please, use Discourse to ask further questions or clarifications.
After various off-line/in person talks, last year I started [a
discussion][0] on Discourse about the existing version scheme of GNOME.
[This topic][1] was also raised in July, and discussed at the release team
meeting during GUADEC. Now that the GNOME 3.37 development cycle is over,
and 3.38 is out of the door, it's time to draw this issue to its conclusion.
In the interest of clarity, I'll present the conclusion first, and then try
to answer common questions. The questions summarise the feedback and
iterations of the change; feel free to read the whole topic on Discourse if
you wish to understand what led to the final form of this change.
## The new GNOME versioning scheme
The next version of GNOME, due to be released in March 2021, will be GNOME
40.
The GNOME 40 development cycle will have three releases:
- 40.alpha
- 40.beta
- 40.rc
Followed by the first stable release, 40.0. Every subsequent stable release
will increment the minor component by 1, so:
- 40.1, 40.2, 40.3, …
After the 40.0 release in March 2021, the next version of GNOME will be 41,
and will follow the exact same pattern.
To recap:
- the new versioning scheme starts at 40
- each new development cycle will increment the version by 1
- each development cycle will have three releases: alpha, beta, rc
(release candidate)
- the first stable release will have a minor version of 0
- each stable release will increment the minor version by 1
## Adopting the new versioning scheme
The new version will be visible in the following components:
- the "GNOME version" field of the "About" section in GNOME Control Center
- the version of GNOME in the Tour application
- the application version in the "About" dialog of core GNOME applications
Additionally, the version of the SDK and Platform run times will follow the
same versioning scheme, so you will depend on, for instance,
org.gnome.Platform//40.
If you maintain an application that is not in the list above, then you can
keep following your own versioning scheme.
Libraries in the platform are not expected to change their existing
versioning scheme, but they are still expected to follow the release
cadence of GNOME, with *at least* an alpha, beta, and rc releases.
If your GNOME core application provides an API—for instance, for
plugins—you can version the programming interface however you prefer, as
long as the user visible version of the application follows the GNOME
scheme.
## Frequently Asked Questions
Q: Why do we need a new versioning scheme?
A: After nearly 10 years of 3.x releases, the minor version number is
getting unwieldy. It is also exceedingly clear that we're not going to bump
the major version because of technological changes in the core platform,
like we did for GNOME 2 and 3, and then piling on a major UX change on top
of that. Radical technological and design changes are too disruptive for
maintainers, users, and developers; we have become pretty good at iterating
design and technologies, to the point that the current GNOME platform, UI,
and UX are fairly different from what was released with GNOME 3.0, while
still following the same design tenets.
Q: Why start at 40?
A: Because the next version would be 3.40, and it's a nice, round number.
The 3.38 release was the 40th release of GNOME, but this discussion came
too late in the cycle to effectively switch, so we can say that, if you
start counting at zero, the next cycle would be the 40th release of GNOME.
By using 40 as the base, we acknowledge what came before, and we don't
introduce a large discontinuity in the number progression, which is
somewhat the point of this change.
Q: Why not 4.0?
A: With GTK 4.0 being released during the next development cycle, calling
the next version of GNOME "4.0" would have unfortunate/unintended
implications about the platform, especially from an engagement and
marketing perspective. We want to decouple GNOME from deep changes in the
application development platform, so that GTK can be released more often,
and [provide "long term support" major versions][2], instead of delaying
development cycles that inevitably end up into "rewrite the world" events.
GNOME is not just a technological platform, but also a set of design
guidelines and an [ethos][3], and bumping the major version along with GTK
does not reflect that.
Q: Why not using the year/month scheme?
A: While date-based versioning schemes do make it easier to resolve the
issues of "when was this version of GNOME released" and "how old is my
version of GNOME compared to the latest one", they still rely on knowing
that the version number is, indeed, date based. Even the "gold standard" of
date-based releases, Ubuntu, has users confused about the version numbers,
as outlined in multiple topics on different user support forums.
