Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add policy on when support is added for new OS versions #5924

Merged
merged 4 commits into from
Oct 15, 2024
Merged

Add policy on when support is added for new OS versions #5924

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2fd7b10
Update supported OS documentation
lbussell Sep 26, 2024
8aebd4a
Fix typo
lbussell Sep 30, 2024
c9c87fd
Remove some unnecessary detail
lbussell Oct 15, 2024
6195d09
Merge remote-tracking branch 'upstream/main' into issue-5756
lbussell Oct 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions documentation/supported-platforms.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,11 @@ This document describes the platforms (OS and architectures) supported by the of

.NET supports [a broad set of operating systems and versions](https://github.com/dotnet/core/blob/master/os-lifecycle-policy.md). When producing container images, it’s impractical to support the full matrix of OS, arch, and .NET version combinations. In practice, images are produced for a select set of operating systems and versions. If official .NET container images aren't provided for your preferred OS, [let us know by opening a discussion](https://github.com/dotnet/dotnet-docker/discussions). Alternatively, you can [author your own .NET images](scenarios/installing-dotnet.md).

New versions of operating systems that we support are added on a best-effort basis, typically within one month.
New OSes are always avialable in the [nightly repositories](https://github.com/dotnet/dotnet-docker/blob/nightly/README.md) first, and then are usually added to the officially supported repos with the next .NET servicing release.
lbussell marked this conversation as resolved.
Show resolved Hide resolved
Occasionally, depending on the specific timing of OS releases and .NET releases, we may add new OSes to the officially supported repos in the middle of a servicing cycle.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer it if we could have a crisp definition of this policy rather than make ad hoc decisions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we remove this clause, are we OK with committing to only releasing new OSes on Patch Tuesdays?

Another thought - what if .NET servicing skips a month as well? Would we want to be up to 2 months behind (the worst-case scenario) for a new Ubuntu or Alpine version? If the intent is to reduce "out of band" work by our team then perhaps the current wording should be updated to "Patch Tuesdays" instead of ".NET Servicing releases.

/cc @richlander

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we need this level of detail. Out-of-band updates are important/impactful for existing tags. They are not important for new tags.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to remove some unnecessary detail while keeping the policy basically the same.

All new OS releases will be accompanied by an [announcement](https://github.com/dotnet/dotnet-docker/discussions/categories/announcements).

### Linux

Each distribution (distro) has a unique approach to releasing, schedule, and end-of life (EOL). This prohibits the definition of a one-size-fits-all policy. Instead, a policy is defined for each supported distro.
Expand Down