How we track OS releases

[richlander]

.NET is supported on multiple operating systems, which have their own releases and lifecycles. It is important that we track "incoming" and "outgoing" releases to ensure that all the correct processes have been followed and to provide early notification to the community.

The current set of supported releases is documented at .NET Supported OS Policy and differs by .NET version.

Our model started with #9623 and was inspired by devcontainers/images#90.

Issues

We track OS support via:

• Uber tracking issue: .NET OS Support Tracking #9638
• Issue label: os-support

Workflow

The following example workflow should be used, for example for Debian 13.

• New issue(s) are created for Debian 13 support per the standard template (much like Add support for Ubuntu 24.10 "Oracular Oriole" #9583).
• A link to the Debian 13 issue is be added to the "incoming" table in the "uber tracking issue" (.NET OS Support Tracking #9638).
• A link to the Debian 13 issue is added to Debian tracking issue (Debian Support Tracking #9636).
• .NET Tactics regularly reviews the uber tracking issue and ensures that we are on track to support "incoming" OS versions, which includes Debian 13.
• After support is in place, Debian 13 is removed from the "incoming" table in the uber tracking issue and is added to the relevant os-support.json/md files per OS Support Policy.
• The Debian 13 release announcement should be added to the Debian 13 tracking issue, much like for our Debian 12 support issue.
• One quarter before Debian 13 goes out of support, it is added to the "outgoing" table in the uber tracking issue.
• New issue(s) are created for Debian 13 end of line per the standard template (much like Debian 11 reached end-of-life on 2024-08-15 #9625).
• .NET Tactics regularly reviews the uber tracking issue and ensures that we are on track to drop support for "outgoing" OS versions, which includes Debian 13.
• After Debian 13 goes out of support, it would be removed from the "outgoing" table in the uber tracking issue. The relevant os-support.json/md files are updated at the same time.
• The Debian 13 EOL announcement is added to one or both of the Debian 13 support/EOL issues, much like the Debian 11 EOL announcement.
• In some cases, a new "incoming" and "outgoing" versions will appear in the same time window. If we do not see that, it is a good to understand why the assumption does not hold.

.NET Team infra must be updated for both "incoming" and "outgoing" events , in multiple repos and branches, for example:

• https://github.com/dotnet/runtime/blob/main/eng/pipelines/coreclr/templates/helix-queues-setup.yml
• https://github.com/dotnet/runtime/blob/main/eng/pipelines/libraries/helix-queues-setup.yml

Patterns for tracking issues

We are best served by issue patterns for managing releases that are low-effort and that take advantage of GitHub features/workflows.

• Pin uber tracking issues as gateway to discover more detailed information.
• Prefer a single tracking issue per distro. Ensure all relevant issues are referenced or (at worst) back-referenced for discoverability. Sub-issues are also good. For example, it should be easy to discover the latter following issue from the former, assuming the former is used as the tracking issue for Debian 11 (even if the former is closed and the latter open).
  • Add support for Debian 11 ("bullseye") #6529
  • Debian 11 reached end-of-life on 2024-08-15 #9625
• Prefer issue naming that is more about the outcome than the task. For example, (at the time of writing) the two tracking issues above are not symmetric on information, task, or tense. The older issue is not well-suited as a tracking issue. The two issue titles would be better written with a terse and more symmetric format, as the following:
  • 'Debian 11 ("bullseye") support'.
  • 'Debian 11 ("bullseye") end-of-life (2024-08-15)'
• Prefer including version numbers and code names in issue titles for intuitive search, like "Debian 13 (Trixie)".
• Prefer bullet lists with issue links. Issue links render with open/closed coloring and encourage good issue titles. Tables can encode much more information but require more care and feeding and are lossy w/rt automatic open/closed status.
• Order bullet lists by ascending order (oldest date first; date we should address first).
• Prefer formats that do not grow w/o bound. Prefer partitioning content that will grow over time, both for length and discoverability. For example, we have a growing issue per distro, while our uber tracking issue is not growing (but changing).
• Make uber/tracking issues as terse as possible to make them usable above the glance and "above the fold". This approach makes the usable as a scorecard. If context is needed, reference it from another issue or markdown file.
• Prefer keeping issues open only if there if they require action / consideration by others.