post-release-activities

# Post-release Activities Skill ## When to Use This Skill Use this skill when assigned an issue asking you to do the post-release activities. You will be given the branch name for the release. If that information is missing, ask for it and don't proceed with doing anything. ## Steps to Follow ### Step 1: Find the release version The branch name only contains the major and minor parts of the version, but not the patch part. To find the full version: 1. Look for `eng/Versions.props` file in the given branch. 2. Find the value of `VersionPrefix`. ### Step 2: Tagging the branch Create a tag for the branch using the version you found in Step 1. The tag name should be `v{version}` (replace `{version}` with the version you found in Step 1). After creating the tag, push it to the remote repository. ### Step 3: Create a GitHub draft release 1. Create a file `release-notes.md` and add the following content to it: `See the release notes [here](https://github.com/microsoft/testfx/blob/main/docs/Changelog.md#{version})` (replace `{version}` with the version you found in Step 1). 2. Run `gh release create v{version} --draft --title v{version} --notes-file release-notes.md`. ### Step 4: Open a PR to main updating the change log files 1. Run the following command to get markdown of the changelog: `gh api --method POST -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" /repos/microsoft/testfx/releases/generate-notes -f 'tag_name=v{version}'` (replace `{version}` with the version you found in Step 1). 2. Classify each entry as either an MSTest change or a Microsoft.Testing.Platform change. 3. MSTest changes go to `docs/Changelog.md` and Microsoft.Testing.Platform changes go to `docs/Changelog-Platform.md`. 4. Classify further the changes of each product into categories like "Added", "Changed", "Fixed", etc. 5. Update the changelog markdown files using the above instructions and following the existing format of those files. 6. When not confident about the classification of a specific change, indicate in the PR description that it requires attention and manual review. This PR must target the `main` branch, not the release branch. ### Step 5: Create a PR to release branch to update patch version Open a PR to the release branch to update the patch version in `eng/Versions.props` file. The new patch version should be one more than the patch version you found in Step 1. Note that in this step, both `TestingPlatformVersionPrefix` and `VersionPrefix` must be updated. ### Step 6: Create a PR to main to update minor version Open a PR to the main branch to update the minor version in `eng/Versions.props` file. The new minor version should be one more than the minor version you found in Step 1, and the patch version should be reset to 0. Note that in this step, both `TestingPlatformVersionPrefix` and `VersionPrefix` must be updated. ### Step 7: Update public samples Open a PR to the main branch to update the product versions of public samples to latest. Public samples are present in `samples/public` directory. ### Step 8: Mark APIs and analyzers as shipped 1. Run `eng/mark-shipped.ps1` (requires PowerShell 7.0). 2. Move the contents of `src/Analyzers/MSTest.Analyzers/AnalyzerReleases.Unshipped.md` (except the first two lines that start with `;`) to `src/Analyzers/MSTest.Analyzers/AnalyzerReleases.Shipped.md`. 3. In `src/Analyzers/MSTest.Analyzers/SuppressionReleases.md`, move the rows for suppressors shipped in the release branch from `## Unshipped` to `## Release {version}` (using the full MSTest version found in Step 1). Create the release section with the existing table format if it does not exist, preserving each suppression ID, suppressed diagnostic ID, and notes. Leave suppressors not included in this release under `## Unshipped`, and remove that section if it becomes empty. If no suppressors were shipped from `## Unshipped`, leave the catalog unchanged. Create a PR to main with these changes.