Would these tags be created regardless if they are being used or would they be created on demand? I question if they are going to be used for every distro/image variant.

I also lean towards on-demand. In fact, I'm not sure we want all distros being tested with floating tags.

Several types

Several or two?

Aren't there going to be cases where images aren't referenced by the runtime?

I don't like this vetting process in a way. If vetting is required you shouldn't be using the version specific tags. I tend to learn towards the .NET Docker Alpine floating tag policy. The new distro is made available one month, the next month the floating tag is updated. This is a more scalable model.

That works as a policy. If we found an issue in runtime, we'd pause roll-out in dotnet-docker. We'd do the same with this system. It does mean that we'll have to be intentional w/ensuring we get coverage in runtime pretty quickly.

As long as the new system is pause-able, it doesn't need vetting.

I'm concerned about this tags being unbounded. At some point in a product release, it is time to turn up the dial on stability and to not move OS versions forward. In a year, we may want to stop updating .NET tags for that reasons. Similarly, "oldest" for .NET 8 and .NET 10 do not match, now. I've already moved .NET 10 to use Alpine 3.21 in dotnet/runtime as "oldest".

I'm a big fan of the model we used for our build images. They are version-specific. I think we should use the same model for build and test images. That approach would be significantly simplifying for teams. Just one model to understand.

https://github.com/dotnet/runtime/blob/main/docs/workflow/using-docker.md#the-official-runtime-docker-images

I'm also not convinced that we need oldest and latest. I think we should just offer one image variant to teams, just like we do for build images. If they need more versions, they can go with DIY.

In dotnet/runtime, the CoreCLR build targets the trailing edge of OS versions we support. Libraries biases to newest.

I think the best model is to:

• Continue to use runtime to hold the baton on "oldest"
• Use libraries to validate that "newest" is OK.
• Push other repos (that use the floating tag) to newest after that, with a single tag (that doesn't say "newest").

Today, these tags are (effectively) exclusively referenced in our own infra. As we move to VMR/UB, there may be more users of these images. We need to be cognizant of that and ensure we don't break them when they attempt to build and test old .NET versions.

I'm a big fan of the model we used for our build images. They are version-specific. I think we should use the same model for build and test images.

That gets outside the scope of what is being addressed here. That's going to move us into producing new images, not just tagging changes. I would encourage you to create a separate issue for this.

I think the best model is to:

• Continue to use runtime to hold the baton on "oldest"
• Use libraries to validate that "newest" is OK.
• Push other repos (that use the floating tag) to newest after that, with a single tag (that doesn't say "newest").

Let me check with you that I'm interpreting this correctly. This means we would have a floating tag that represents the latest version. If repos want an older version, they should use a version-specific tag. And libraries would still use a version-specific tag, targeting the latest, that we can use for vetting.

I don't see why we need new images. I'm only talking about tagging.

Let's make this concrete. We should model this for .NET 8 and 10 for Alpine. As I said, I'd like to retain the ability to stop taking Alpine changes for .NET 8 late in the .NET 8 lifecycle (last 6 months).

I don't see why we need new images. I'm only talking about tagging.

I thought you were referring to using net8.0 and net9.0 tagging like we do for the build images.

Yes. For our build images, it's completely different content. For this, I'm suggesting just different tags, all handled in manifest.json.

Imagine just before .NET 9 EOL:

• alpine-net9.0 -- same as alpine-3.23-helix-amd64, referenced in release/9.0 branches
• alpine-net10.0 -- same as alpine-3.24-helix-amd64, referenced in release/10.0 branches

The .NET 9 image is eventually pinned to Alpine 3.23 while the .NET 10 image keeps on marching forward. The reason is that .NET 9 is in maintenance and we value high stability and low cost at that point.

We don't need any special tools for this. We could do this now.

Some thoughts on users of these tags:

• Should only update tags (from Alpine 3.23 to 3.24, for example) in the middle weeks of the month. If Patch Tuesday is the B week, then we should update change these tags on a C or D week, ideally also on a Tuesday. We don't want to disrupt servicing activities.
• If a change breaks one or a few teams, it is their responsibility to fix their code. That's part of the terms of use of these tags. If a change breaks most users, then the tag change should be reverted.
• The tags should only be updated after they test cleanly in runtime, otherwise, we're in YOLO mode.
• Not appropriate for repos that have -staging branches, like https://github.com/dotnet/runtime/tree/release/8.0-staging. That pattern places a high premium on a commit encoding/representing all aspects of code and config. Floating tags are antithetical to that approach.

If Patch Tuesday is the B week, then we should update change these tags on a C or D week, ideally also on a Tuesday. We don't want to disrupt servicing activities.

Timing is a good point. Wouldn't we want to make these prior to code complete?

Yes. Perhaps that's just the C week. I don't know what that timing is so really just bringing up the topic. I am certain the B week is a bad choice. There is always the chance that we'll regret something we shipped and need to make a quick update in the B week.