Skip to content

Should we expect Windows container base images labelled 21H1/10.0.19043.X? #117

@TBBle

Description

@TBBle

In a discussion related to adamrehn/ue4-docker#164, we realised with growing concern that there doesn't seem to be hide-nor-hair of either a Windows Server SAC 21H1 release, and neither 21H1 nor 10.0.19043.985 are listed in the tags on https://hub.docker.com/_/microsoft-windows-servercore

That said, I also noticed that the Windows Server container update history has always marked the feature-enablement releases (1909, 20H2) with the same kernel as their base release (1903, 2004), which matches my existing intuition that those containers would be cross-compatible, but conflicts with the Windows container version compatibility docs regarding process isolation.

So for those use-cases where it's useful to have a Windows 10 client with the recommended release (currently 21H1), even if there's no matching Windows Server SAC release to go to production with, do any of the following apply?

  • ❌ Process-isolation of 2004 and 20H2 images on 21H1 is supported, and the cross-version compatibility tables were simply overlooked?
  • ❌ There will be a 21H1 set of container images in the June updates, and it's only missing now because the May update of the container images for 10.0.1904n.985 was a week before Windows 10 21H1 was released?
  • ❌ Is there a Windows Server SAC 21H1 release in the pipeline that will bring 10.0.19043.X container images, and we just haven't heard much about it because everyone's focused on (excited for) Windows Server LTSC 2022?

Edit: None of the three dot-points above have proved out, in retrospect.

Metadata

Metadata

Assignees

Labels

questionFurther information is requested

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions