What is the problem you're trying to solve

Windows Server LTSC 2022 kernel build 20348 offers a stable ABI for Windows releases up to (at least) the next Windows Server LTSC build.

As such, the current logic for matching Windows hosts and container images in a manifest list/image index by equality-testing the build version (currently being updated in #6491 but still the same behaviour as before) is overly-restrictive on these cases.

If the container images are pulled directly by manifest, they function correctly.

See microsoft/Windows-Containers#170 and microsoft/Windows-Containers#179 for some existing failed use-cases.

Describe the solution you'd like

When the host build version is 20348 or greater, then it should match any build version 20348 up to itself. I expect preference would be towards higher build images when the choice occurs.

hcsshim's cri-containerd test suite includes an implementation of the version-matching behaviour we want, although it's picking from a hard-coded list of images rather than a manifest list's contents.

Additional context

The only currently-active released Windows build versions that meet this criteria are 20348 (Windows Server LTSC 2022) and 22000 (Windows 11), and there are no container base images for Windows 11. More container images bases may appear due to either evolution of Windows Server non-LTSC releases, but it's also quite possible that there won't be new container base image versions until the following Windows Server LTSC release.

For reference, the stable-API behaviour was announced in a blog post and has been discussed in the relevant GitHub ticket.