Discuss tag inferencing for .NET 10

[richlander]

We are changing container defaults for .NET 10, to Ubuntu from Debian, per dotnet/dotnet-docker#5709. I don't think this change is dramatic, but could result in some subtle differences (and perhaps affect our testing). At the very least, it is worth a discussion.

At the time of the .NET 10 release, the relevant Debian and Ubuntu releases will be:

• Debian 13 "Trixie".
• Ubuntu 24.04 (Noble Numbat)

Let's consider some scenarios, either unconfigured or configured with ContainerFamily:

• Default/unconfigured case -- results in 10.0 (Ubuntu image; different result than 9.0)
• noble -- results in 10.0-noble
• noble-chiseled -- results in 10.0-noble-chiseled
• trixie-slim -- results in 10.0-trixie-slim (Debian image)

Only the unconfigured case is different than the 9.0 behavior. All the other cases are the same (modulo distro versions). Other than testing, I don't imagine a change for our inferencing logic. I'm skipping all the scenarios with architecture. I imagine they would be unaffected.

It occurs to me that we could offer a bit more value with some more convenience cases. I suspect that most users don't care about these code names, like noble and trixie, but just want the correct distro version for the .NET version they are using.

• ubuntu -- results in 10.0-noble
• ubuntu-chiseled -- results in 10.0-noble-chiseled
• chiseled -- results in 10.0-noble-chiseled
• debian -- results in 10.0-trixie-slim

If a user had set ContainerFamily=ubuntu and changed their TargetFramework to 11.0, then they would get a new Ubuntu LTS version (the only after Noble).

This is actually a different behavior than ContainerFamily=alpine since we have an actual alpine tag and Alpine has a different release schedule (which is why we have the alpine tag).

We have avoided having actual tags, like 8.0-ubuntu because we cannot update them, from 20.04 to 22.04 to 24.04, due to compatibility. We are certain to break people. We also don't want to expand our tag tables any more than necessary. So, this is a question of whether we think it is appropriate to offer ContainerFamily hint information that doesn't directly match container images.

Some readers may wonder why we use the code names to start with. We do that for two reasons:

• The code names are commonly used for Docker Hub official images, hencse
• The code names avoid having two version numbers in our tags

[baronfel]

The 'ubuntu -> TFM-specific-release name' mapping definitely seems like something we could introduce as part of the 9 cycle as well to prep the path for users.

[richlander]

I was suggesting that for Debian as well. The rationale applies equally to both.