-------------------- Start of forwarded message --------------------
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=8.43.85.24; helo=smtp.gnome.org; envelope-from=desktop-devel-list-bounces@???; receiver=<UNKNOWN>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to:cc;
bh=yqtpy+azIPtMjjjUnUAzHbeF/UQx9wKqblxWVRH91Bw=;
b=fZTBh1v4UmbmwxIj+dtb2K1XMnrZjqkxhnSXFXYNVW4Dag6yC6Lz1b/ueWzCs6IrcR
1jLqD5tA+dm4Y526OdcLXGFiQnP6OxG8+mFdZAacaQo1EmiTXRj1CRL3XfEtNDRhhmSB
7PG05SUrikXcCjskdmM46MZXuCLXcCljAr8cyxRrkXP2EMSnHEv5Sf4rQUC92J4ilx4Y
FDMyyL+D1pLrJRGUPOdQ5eF+TE30iIJ60FlS9sxVPkRExO3pfpEJ0KUgSXyb9mIZ3zbd
i4Bwk5hybxnvAnj9DdHV+6zvMymHSS5CwKuEvTZufmbBh3FAuIpLJuiet46ci+idfE5n
lQCQ==
Date: Wed, 16 Sep 2020 16:02:50 +0100
Subject: New GNOME versioning scheme
To: Desktop Development List <desktop-devel-list@???>
From: Emmanuele Bassi via desktop-devel-list <desktop-devel-list@???>
Cc: gtk-app-devel-list list <gtk-app-devel-list@???>,
distributor-list@???
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.
Additionally, a date-based versioning scheme requires on a twice-per-year
schedule, with stable releases that continue over the span of a year each,
introduces possible collisions and uncertainty, unless more numeric
components are added, thus making version numbers more complicated.
Q: What happened to even/odd (or "Linux kernel style") versions?
A: Just like the Linux kernel, we found that there's no real advantage in
an even/odd split any more. Not many people actually use the odd-numbered
versions of GNOME, even when distributions package them. From the
perspective of application developers, especially with the advent of
bundling technologies like Flatpak, you will either use the bleeding edge
"nightly" snapshots, or, more likely, you'll use the current stable run
times until you are ready to update them.
Q: Why only three development releases?
A: With the advent of nightly builds and continuous integration and
delivery pipelines, there's no real advantage in having multiple alpha and
beta snapshots any more, considering the amount of people actually using
them outside of GNOME maintainers (and the odd packager); they are mostly
busy work for the release team, at this point. Maintainers do tend to skip
the alpha releases, and having more releases in the beta/release candidate
period usually injects more stress into the development process.
Nevertheless, if maintainers wish to do multiple releases, they are
absolutely free to do so. The release team will guarantee those three
development releases for the whole of GNOME.
Q: Does this versioning scheme apply to every GNOME project?
A: The intended audience for this versioning scheme is GNOME users.
Libraries have difference constraints, and thus do not need to conform to
it, and neither do applications that are not in the core applications set,
as defined by the release team. Maintainers are free to follow the same
scheme, or adopt their own. Some applications expose a programmable
interface for out of tree plugins; the interface can have its own
versioning scheme, or it can follow the version of the application.
Q: What about packaging development releases of GNOME? How do we deal with
the new versions?
A: Since packaging rules vary from distribution to distribution, and from
packaging format to packaging format, it is left to the downstream
packagers's judgement how to translate the "dot-alpha", "dot-beta", and
"dot-rc" versions into something that can be appropriately represented by
their downstream project. If the packaging rules or format do not allow
alphabetic components, or do not sort alphabetic components before numeric
ones, we recommend using something like:
- .0alpha, .0beta, .0rc
- .0~alpha, .0~beta, .0~rc
- .0a, .0b, .0rc
which should sort in the correct order, and do so before the .0, .1, … of
the stable releases.
Q: How does this scheme impact the branch naming when opening a new
development cycle?
A: The stable branches will keep the same policy, "gnome-" + version; so
you will have "gnome-40", "gnome-41", and so on, and so forth.
Q: What version number should I use between the latest stable release and
the new development cycle?
A: You should use the version of the next stable, plus the "alpha"
component. Once you cut the alpha release, you update to "beta"; once you
cut the beta release, you update to "rc"; once you cut the release
candidate, you update to 0.
Q: Can I make additional alpha/beta/rc releases? How do I call them?
A: Of course you can do more releases, if you want to; you can use a scheme
such as:
- .alpha.0, alpha.1, …
- .beta.0, beta.1, …
- .rc.0, .rc.1, …
to distinguish them.
Q: I do pre-release version bumps; what do I do, now?
A: The preferred model is to move to post-release version bumps. In other
words: you change the version of your project *after* cutting a release.
For instance, a typical development cycle might look like this:
- you just released "40.0" (first stable release)
- open the development cycle for GNOME 41
- create the `gnome-40` branch
- bump the version of your project to "41.alpha" in your development
branch
- commit the change
- hack, hack, hack
- release "41.alpha"
- update the `NEWS` file
- commit the change
- tag the commit
- bump the version of your project to "41.beta"
- commit the change
- hack, hack, hack
- release "41.beta"
- update the `NEWS` file
- commit the change
- tag the commit
- bump the version of your project to "41.rc"
- commit the change
- we are in freeze, so hack with caution
- release "41.rc"
- update the `NEWS` file
- commit the change
- tag the commit
- we are now in hard code freeze, so no hacking
- release "41.0"
This is a change that might take a bit of an adjustment, but we feel it's
the best compromise towards a consistent versioning behavior.
Q: This is nonsensical. Why do you want to change the versioning scheme at
all? It's just numbers!
A: Numbers, like words, have meaning, and tell a story. With a change in
the versioning scheme we wish to communicate the fact that GNOME doesn't
see major versions of the development platform as the driving force behind
major changes in its user experience; and that radical changes to the user
experience are going to be introduced progressively, so that we can refine
and iterate over them in time, instead of dumping them in our users lap.
## Additional questions
Feel free to discuss this topic on Discourse, and to reach out to the
release team for additional clarifications.
On behalf of the GNOME release team,
Emmanuele Bassi
[0]:
https://discourse.gnome.org/t/straw-man-proposal-changing-the-gnome-versioning-scheme/1964
[1]:
https://mail.gnome.org/archives/desktop-devel-list/2020-July/msg00004.html
[2]:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
[3]:
https://blogs.gnome.org/aday/2017/08/08/the-gnome-way/
--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@???
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
-------------------- End of forwarded message --------------------
