From 7102dc52e6b03248da1f01b3a8a4b83c6d7a1316 Mon Sep 17 00:00:00 2001 From: Adrian Vovk Date: Wed, 22 May 2024 18:06:54 -0400 Subject: [PATCH 1/2] os-release: Add RELEASE_TYPE= This will allow GUIs to customize their behavior a little based on the type of release. For example, an OS installer may display a warning/disclaimer if RELEASE_TYPE=prerelease. The software updates app might be a bit more insistent about upgrading to the next major release if RELEASE_TYPE=stable than if RELEASE_TYPE=lts --- man/os-release.xml | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/man/os-release.xml b/man/os-release.xml index afdb21fc57..32edc088df 100644 --- a/man/os-release.xml +++ b/man/os-release.xml @@ -325,6 +325,29 @@ + + + RELEASE_TYPE= + + A lower-case string (no spaces or other characters outside of 0-9, a-z, ".", + "_", and "-"), describing what kind of release this version of the OS is. Known values follow: + stable is for normal releases of the system, suitable for production use. + Generally, stable releases become end-of-life soon after the next major stable release is out. + Examples include Fedora 40, Ubuntu 23.10, OpenSUSE Tumbleweed, and Arch Linux. + lts is for long term support releases of the system, suitable for production + use and supported for an extended period of time. Generally, LTS releases continue to recieve + support even if newer major releases of the distribution are available. Examples include Ubuntu + 24.04, Debian 12 Bookworm and RHEL 9.4. + pre-release is for unstable versions of the system, unsuitable for production + use, such as alpha, beta, or rolling unstable releases. Examples include Fedora Rawhide, Debian + Testing, Fedora 40 Beta, and GNOME OS Nightly. + If unset, or an unknown value, assume that the release is stable. + + Examples: RELEASE_TYPE=pre-release, RELEASE_TYPE=lts. + + + + To summarize: if the image updates are built and shipped as comprehensive units, From d25a9bfa8f8bd42b769dbf2f9786348864cf5e08 Mon Sep 17 00:00:00 2001 From: Adrian Vovk Date: Thu, 23 May 2024 23:39:52 -0400 Subject: [PATCH 2/2] os-release: Introduce experiment RELEASE_TYPE This is for experimental builds of the OS made to test some specific WIP feature. For example, let's say the distro in question is Asahi Linux and Apple just released the M3 SoC. The Asahi developers will start porting to the M3, and will quickly generate builds of Asahi Linux that can technically boot but aren't ready for any kind of daily use. These images are marked as experimental, and can be shared among the developers. If a user somehow stumbles upon one of these images and tries to install it, they'll be warned that they're about to install an experimental Apple M3 port of Asahi Linux. Eventually, once the Asahi developers think that their M3 port is ready for a wider audience, they can merge it into the mainline Asahi repos, where it will be distributed through the usual nightly CI builds (where RELEASE_TYPE=pre-release; M3 support is no longer experimental). --- man/os-release.xml | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/man/os-release.xml b/man/os-release.xml index 32edc088df..28384d352a 100644 --- a/man/os-release.xml +++ b/man/os-release.xml @@ -341,6 +341,8 @@ pre-release is for unstable versions of the system, unsuitable for production use, such as alpha, beta, or rolling unstable releases. Examples include Fedora Rawhide, Debian Testing, Fedora 40 Beta, and GNOME OS Nightly. + experiment is for experimental builds of the system, created specifically to + test some work-in-progress feature. This is meant to be used in combination with EXPERIMENT=. If unset, or an unknown value, assume that the release is stable. Examples: RELEASE_TYPE=pre-release, RELEASE_TYPE=lts. @@ -466,6 +468,47 @@ + + EXPERIMENT= + + A human-presentable description of what makes this build of the OS experimental. + This field is optional. The RELEASE_TYPE field should be set to experiment + if this field is set, otherwise clients should ignore this field. + + This description is intended to be exposed at system installation time, or in "About this system" UIs, + to warn the user that they're installing/running an experimental build of the OS. If RELEASE_TYPE + is experiment but this field is unset, the UI should still warn the user, but it + will be unable to explain what exactly is experimental about the current build of the OS. + + Examples: EXPERIMENT="Switch to DNF5" for an experimental build of Fedora + Linux made to test DNF5, EXPERIMENT="Port to Apple M3 chip" for experimental + builds of Asahi Linux ported to the Apple M3 SoC, + EXPERIMENT="Mutter !1441: Dynamic triple/double buffering (v4)" for builds of GNOME + OS created by Mutter's CI for merge request !1441. + + + + + + EXPERIMENT_URL= + + The main informational page about what makes the current OS build experimental, where users + can learn more about the experiment's status and potentially leave feedback. This field is optional. The + EXPERIMENT= field should be set if this one is, although clients must be robust against + either field not being set. + + The value should be in RFC3986 format, and should be + http: or https: URLs. Only one URL shall be listed in the + setting. + + Examples, corresponding to the examples above in EXPERIMENT=: + EXPERIMENT_URL="https://fedoraproject.org/wiki/Changes/SwitchToDnf5", + EXPERIMENT_URL="https://github.com/AsahiLinux/docs/wiki/M3-Series-Feature-Support", + EXPERIMENT_URL="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441". + + +