Update release checklists (#4232)

Author: mthalman

.github/ISSUE_TEMPLATE/releases/dotnet-monitor-release.md

@@ -4,28 +4,33 @@
 
 _The set of .NET versions that are being released as a unit._
 
-* runtime/SDK
+* .NET <major/minor version>
+  * Runtime: <full version>
+  * ASP.NET Core: <full version>
+  * SDK: <full version>
+  * Monitor: <full version>
 
 ## 1. Main Branch Tasks
 
-1. - [ ] Merge appropriate commits from nightly branch.  Things to check:
+1. - [ ] Merge appropriate commits from nightly branch on local repo. Identify what to merge by checking [commit history](https://github.com/dotnet/dotnet-docker/commits/nightly) since the last release. Things to check:
       - [ ] New/EOL distro
       - [ ] Infrastructure changes
       - [ ] PowerShell version
       - [ ] Check for additional changes by diffing the main and nightly branches
       - [ ] <add link to PR/commit>
-1. - [ ] Check whether a change has been made to a Dockerfile that is shared by multiple .NET versions. If a change has been made and the .NET versions that share that file are not being released at the same time, define a separate Dockerfile to isolate the change to the .NET version that's being released. Conversely, after a shared Dockerfile has diverged in such a way, it should be combined again into a shared Dockerfile when the other other .NET version is released. Shared Dockerfiles to check:
-      - [ ] 3.1 runtime-deps shared with 6.0, and 7.0
-1. - [ ] Wait for .NET archive files (.zip, .tar.gz) to be available at blob storage location
-1. - [ ] Run `update-dependencies` tool to update all the necessary files to reflect the specified .NET versions (run this command for each version being released):
+2. - [ ] Check whether a change has been made to a Dockerfile that is shared by multiple .NET versions. If a change has been made and the .NET versions that share that file are not being released at the same time, define a separate Dockerfile to isolate the change to the .NET version that's being released. Conversely, after a shared Dockerfile has diverged in such a way, it should be combined again into a shared Dockerfile when the other other .NET version is released. Shared Dockerfiles to check:
+      - [ ] 6.0 runtime-deps shared with 7.0
+3. - [ ] Run `update-dependencies` tool to update all the necessary files to reflect the specified .NET versions (run this command for each version being released):
       - [ ] `./eng/Set-DotnetVersions.ps1 -ProductVersion <major/minor version> -SdkVersion <sdk> -RuntimeVersion <runtime> -AspnetVersion <aspnet>`
-1. - [ ] Inspect generated changes for correctness
-1. - [ ] Commit generated changes
-1. - [ ] Create PR
-1. - [ ] Get PR signoff
-1. - [ ] Merge PR
-1. - [ ] Wait for changes to be mirrored to internal [dotnet-docker repo](https://dev.azure.com/dnceng/internal/_git/dotnet-dotnet-docker) (internal MSFT link)
-1. - [ ] Build images - Queue build stage of [dotnet-docker pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=373) (internal MSFT link) with variables:
+      - [ ] .NET Monitor has its own major/minor versioning scheme, so it is updated separately:
+         - [ ] `./eng/Set-DotnetVersions.ps1 -ProductVersion <major/minor version> -MonitorVersion <version>`
+4. - [ ] Wait for .NET archive files (.zip, .tar.gz) to be available at blob storage location
+5. - [ ] Inspect generated changes for correctness
+6. - [ ] Create PR
+7. - [ ] Get PR approval
+8. - [ ] Merge PR
+9. - [ ] Wait for changes to be mirrored to internal [dotnet-docker repo](https://dev.azure.com/dnceng/internal/_git/dotnet-dotnet-docker) (internal MSFT link)
+10. - [ ] Run [dotnet-docker pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=373) (internal MSFT link) with variables:
 
       All releases:
 
@@ -34,29 +39,28 @@ _The set of .NET versions that are being released as a unit._
       Servicing release:
 
           noCache: true
-1. - [ ] Wait for NuGet packages to be published during release tic-toc
-1. - [ ] Test and publish images - Queue build of [dotnet-docker pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=373) (internal MSFT link) with variables:
+11. - [ ] Confirm successful pipeline run
+12. - [ ] Wait for NuGet packages to be published during release tic-toc
+13. - [ ] Run [dotnet-docker pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=373) (internal MSFT link) with variables:
 
       All releases:
 
           stages: test;publish
           sourceBuildId: <Build ID from the build stage>
-1. - [ ] Confirm READMEs have been updated in [Docker Hub](https://hub.docker.com/_/microsoft-dotnet)
+14. - [ ] Confirm successful pipeline run
 
 ## 2. Sample Images (Not needed for Preview-only release)
 
-1. - [ ] Confirm build for [dotnet-docker-samples](https://dev.azure.com/dnceng/internal/_build?definitionId=376) (internal MSFT link) was queued. This will be queued automatically by [dotnet-docker-tools-check-base-image-updates](https://dev.azure.com/dnceng/internal/_build?definitionId=536) when it detects that the product images have been updated (detection runs on a schedule). Alternatively, you can manually queue the samples build.
-1. - [ ] Confirm sample images have been ingested by MCR
-1. - [ ] Confirm README has been updated in Docker Hub for [microsoft-dotnet-samples](https://hub.docker.com/_/microsoft-dotnet-samples/)
+1. - [ ] Confirm run for [dotnet-docker-samples pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=376) (internal MSFT link) was queued. This will be queued automatically by [dotnet-docker-tools-check-base-image-updates](https://dev.azure.com/dnceng/internal/_build?definitionId=536) when it detects that the product images have been updated (detection runs on a schedule). Alternatively, you can manually queue the samples build.
+1. - [ ] Confirm successful pipeline run
 
 ## 3. Nightly Branch Tasks (Not needed for Preview-only release)
 
-1. - [ ] Merge main branch to nightly
-1. - [ ] Run the same `update-dependencies` command(s) in nightly that were run for the main branch
+1. - [ ] Merge main branch to nightly on local repo
+1. - [ ] Run the same `Set-DotnetVersions.ps1` command(s) in nightly that were run for the main branch
 1. - [ ] Inspect generated changes for correctness
-1. - [ ] Commit generated changes
 1. - [ ] Create PR
-1. - [ ] Get PR signoff
+1. - [ ] Get PR approval
 1. - [ ] Merge PR
-1. - [ ] Wait for automatically queued CI build to finish on [dotnet-docker-nightly pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=359) (internal MSFT link)
-1. - [ ] Confirm READMEs have been updated in [Docker Hub](https://hub.docker.com/_/microsoft-dotnet)
+1. - [ ] Confirm CI build is automatically run for [dotnet-docker-nightly pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=359) (internal MSFT link)
+1. - [ ] Confirm successful pipeline run

.github/ISSUE_TEMPLATE/releases/dotnet-release.md

@@ -29,4 +29,5 @@ Distro: <name/version>
 ## Main Branch Tasks
 
 1. - [ ] After the product teams have signed off on the new distro, merge these changes to the main branch as part of the [release process](dotnet-release.md) for the next .NET release
+      - [ ] For Alpine, follow the [policy](https://github.com/dotnet/dotnet-docker/blob/main/documentation/supported-tags.md) to only update the floating `alpine` tag one month after the release of the new Alpine version. Since nightly will already have the floating tag updated, the initial release of the new Alpine version to main will need to account for this and keep it set to the older version for one month.
 1. - [ ] Create an announcement (example: [Alpine 3.10](https://github.com/dotnet/dotnet-docker/issues/1418)) unless the new distro is added only for pre-release versions in which the announcement would be incorporated in the pre-release notes.

.github/ISSUE_TEMPLATE/releases/new-distro-release.md

@@ -6,7 +6,7 @@ Windows version: <version>
 
 1. - [ ] Ensure a ["New Windows Release" issue](https://github.com/dotnet/docker-tools/blob/main/.github/ISSUE_TEMPLATE/releases/new-windows-release.md) exists for docker-tools repo
 1. - [ ] Copy the Dockerfiles of the most recent published Windows version for all supported .NET versions and place them in a version-specific folder under their respective variants (runtime, aspnet, sdk)
-1. - [ ] Modify the Dockerfiles as appropriate for any specific changes related to the new Windows version
+1. - [ ] Modify the Dockerfile templates if there are any specific changes needed that are related to the new Windows version
 1. - [ ] Update [manifest.json](https://github.com/dotnet/dotnet-docker/blob/nightly/manifest.json) to reference the new set of Dockerfiles with the appropriate tags
 1. - [ ] Update the [test data](https://github.com/dotnet/dotnet-docker/blob/nightly/tests/Microsoft.DotNet.Docker.Tests/TestData.cs) to include the new Windows version
 1. - [ ] Update the [tags metadata templates](https://github.com/dotnet/dotnet-docker/tree/main/eng/mcr-tags-metadata-templates) to include the new Windows version
@@ -16,16 +16,14 @@ Windows version: <version>
 1. - [ ] Test the images
       1. - [ ] Create a local VM of the new Windows version
       1. - [ ] Clone this repo with the above changes onto the VM
-      1. - [ ] Run `.\build-and-test.ps1 -OS nanoserver-<VERSION>` to build and test your changes
-1. - [ ] Commit generated changes
+      1. - [ ] Run `.\build-and-test.ps1 -OS nanoserver-<VERSION>` to build and test your changes for Nano Server
+      1. - [ ] Run `.\build-and-test.ps1 -OS windowsservercore-<VERSION>` to build and test your changes for Windows Server Core
 1. - [ ] Create PR
 1. - [ ] Get PR signoff
-1. - [ ] Merge PR as part of the main branch [release process](dotnet-release.md) for the next .NET release
-1. - [ ] Wait for automatically queued CI build to finish on [dotnet-docker-nightly pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=359) (internal MSFT link)
-1. - [ ] Confirm READMEs have been updated in [Docker Hub](https://hub.docker.com/_/microsoft-dotnet)
+1. - [ ] Merge PR and build/publish as part of the main branch [release process](dotnet-release.md) for the next .NET release
 1. - [ ] Create an announcement (example: [Nano Server, version 20H2](https://github.com/dotnet/dotnet-docker/issues/2322))
 1. - [ ] Update the samples to reference the new Windows version:
-      - [ ] [Nano Server sample Dockerfiles](https://github.com/dotnet/dotnet-docker/tree/main/samples)
+      - [ ] [Nano Server and Windows Server Core sample Dockerfiles](https://github.com/dotnet/dotnet-docker/tree/main/samples)
       - [ ] [manifest.samples.json](https://github.com/dotnet/dotnet-docker/blob/main/manifest.samples.json)
 
 ## Nightly Branch Tasks

.github/ISSUE_TEMPLATE/releases/new-windows-release.md

@@ -5,14 +5,13 @@
 1. - [ ] Run the [`Get-BaseImageStatus.ps1`](https://github.com/dotnet/dotnet-docker/blob/main/eng/common/Get-BaseImageStatus.ps1) script and wait until the Windows images have been updated as part of the Windows Patch Tuesday release process. This script will display when the dependent Windows images were last updated. Wait until all the images show that they have been recently updated. "Recently updated" amounts to be having been updated within the past week or so; images from a month ago should be considered to be the old version.
 
           ./eng/common/Get-BaseImageStatus.ps1 -Continuous
-1. - [ ] Queue build of [dotnet-docker pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=373) (internal MSFT link) with the following parameters:
+1. - [ ] Run [dotnet-docker pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=373) (internal MSFT link) with the following parameters:
 
           imageBuilder.pathArgs: --path '*nanoserver*' --path '*windowsservercore*'
-1. - [ ] Queue build of [dotnet-docker-nightly pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=359) (internal MSFT link) with the following parameters:
+1. - [ ] Confirm successful run of dotnet-docker pipeline
+1. - [ ] Run [dotnet-docker-nightly pipeline](https://dev.azure.com/dnceng/internal/_build?definitionId=359) (internal MSFT link) with the following parameters:
 
           imageBuilder.pathArgs: --path '*nanoserver*' --path '*windowsservercore*'
-1. - [ ] Confirm `Last Modified` field has been updated in Docker Hub for [microsoft-dotnet](https://hub.docker.com/_/microsoft-dotnet)
-1. - [ ] Confirm build for [dotnet-docker-samples](https://dev.azure.com/dnceng/internal/_build?definitionId=376) (internal MSFT link) was queued. This will be queued automatically by [dotnet-docker-tools-check-base-image-updates](https://dev.azure.com/dnceng/internal/_build?definitionId=536) when it detects that the product images have been updated (detection runs on a schedule). Alternatively, you can manually queue the samples build.
-1. - [ ] Confirm sample images have been ingested by MCR
-1. - [ ] Confirm `Last Modified` field has been updated in Docker Hub for [microsoft-dotnet-samples](https://hub.docker.com/_/microsoft-dotnet-samples/)
-1. - [ ] Reply to .NET Release team with a status update email
+1. - [ ] Confirm successful run of dotnet-docker-nightly pipeline
+1. - [ ] Confirm run for [dotnet-docker-samples](https://dev.azure.com/dnceng/internal/_build?definitionId=376) (internal MSFT link) was queued. This will be queued automatically by [dotnet-docker-tools-check-base-image-updates](https://dev.azure.com/dnceng/internal/_build?definitionId=536) when it detects that the product images have been updated (detection runs on a schedule). Alternatively, you can manually queue the samples build.
+1. - [ ] Confirm successful run of dotnet-docker-samples pipeline