| name | post-release-activities |
| description | Systematic activities that need to be performed after a release is done. |
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:
- Look for
eng/Versions.props file in the given branch.
- 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
- 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).
- 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
- 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).
- Classify each entry as either an MSTest change or a Microsoft.Testing.Platform change.
- MSTest changes go to
docs/Changelog.md and Microsoft.Testing.Platform changes go to docs/Changelog-Platform.md.
- Classify further the changes of each product into categories like "Added", "Changed", "Fixed", etc.
- Update the changelog markdown files using the above instructions and following the existing format of those files.
- 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
- Run
eng/mark-shipped.ps1 (requires PowerShell 7.0).
- 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.
Create a PR to main with these changes.
