Release process

Some high-level notes for the team when doing a release.

1. Determine if this will be a dev, rc, or stable release.
2. Figure out the build number for the next release.
   1. If unsure, check https://pypi.org/project/qsharp/#history or https://www.npmjs.com/package/qsharp-lang?activeTab=versions to see what the prior version was.
3. To set the version for a new stable release across the codebase, run the ./version.py script with the --set option, i.e. python version.py --set 1.20.0
4. For a stable release, draft a release in GitHub, and update the ./source/vscode/changelog.md with similar contents.
   1. Note: I find it useful to generate the release notes on GitHub, but then edit in the changelog.md, and when done there paste the markdown for the release back into the GitHub release.
   2. You can type the new tag in GitHub and ask it to 'Generate' the release notes. The tag will not get created until the release is published.
5. For a stable release, open a PR that bumps the version numbers and changelog.md contents (if needed). Merge when ready.
6. Navigate internally to the "microsoft.qsharp-lang.release" pipeline in ADO and click "Run pipeline"
7. Ensure the "branch/tag" is set as appropriate (usually main).
8. Click on the "Variables" field and ensure BUILD_NUMBER is the patch version chosen above, and BUILD_TYPE is dev, rc, or stable
9. Click "Run" to start the pipeline. It usually takes about 12 - 15 mins to build all artifacts for all platforms.
10. After building the artifacts, it will pause for approval. Under a heading titled "Related" you should see something like "8 published" as shown below

6. Click on this and ensure the artifacts look right (versions, pre-release tags, file sizes, etc.) as a final check.
7. If so, click on "Review" and approve proceeding to the publish stage.
8. The 3 "publish" jobs may take up to 5 mins, and the VS Code Marketplace validation may take another few mins before the new version is "live".
9. Validate that versions are showing up as expected on PyPI, npm, and VS Code marketplace.
10. If this was a stable release, publish the GitHub release drafted earlier with the appropriate tag. Note that the tag will be created when the release is published if it was not created ahead of time.
    1. IMPORTANT: Keep the latency as low as possible between the release artifacts going live, and the GitHub release being tagged, as the VS Code release notes and library manifest will reference the new tag.
    2. You could also publish the GitHub release when approving the 'Review' to release the artifacts in ADO. The only risk here is if the publishing pipeline fails (e.g. the ESRP tasks), then the release won't actually be out until resolved.