Releasing (write access required)

Determine the new version number. We default to increasing the patch version number, but make our own judgement about whether a change is big enough to warrant a minor version bump. Common reasons for a minor bump could include:
- Making substantial new features available to all users. This can include lifting a feature flag.
- Breakage in compatibility with recent versions of the CLI.
- Minimum required version of VS Code is increased.
- New telemetry events are added.
- Deprecation or removal of commands.
- Accumulation of many changes, none of which are individually big enough to warrant a minor bump, but which together are. This does not include changes which are purely internal to the extension, such as refactoring, or which are only available behind a feature flag.
Create a release branch named after the new version (e.g. v1.3.6):
- For a regular scheduled release this branch will be based on latest main.
  - Make sure your local copy of main is up to date so you are including all changes.
- To do a minimal bug-fix release, base the release branch on the tag from the most recent release and then add only the changes you want to release.
  - Choose this option if you want to release a specific set of changes (e.g. a bug fix) and don't want to incur extra risk by including other changes that have been merged to the main branch.
```
git checkout -b <new_release_branch> <previous_release_tag>
```
Run the "Run CLI tests" workflow and make sure the tests are green.
- You can skip this step if you are releasing from main and there were no merges since the most recent daily scheduled run of this workflow.
Double-check the CHANGELOG.md contains all desired change comments and has the version to be released with date at the top.
- Go through PRs that have been merged since the previous release and make sure they are properly accounted for.
- Make sure all changelog entries have links back to their PR(s) if appropriate.
Double-check that the extension package.json and package-lock.json have the version you intend to release. If you are doing a patch release (as opposed to minor or major version) this should already be correct.
Commit any changes made during steps 4 and 5 with a commit message the same as the branch name (e.g. v1.3.6).
Open a PR for this release.
- The PR diff should contain:
  - Any missing bits from steps 4 and 5. Most of the time, this will just be updating CHANGELOG.md with today's date.
  - If releasing from a branch other than main, this PR will also contain the extension changes being released.
Build the extension using npm run build and install it on your VS Code using "Install from VSIX".
Go through our test plan to ensure that the extension is working as expected.
Create a new tag on the release branch with your new version (named after the release), e.g.
```
git tag v1.3.6
```
Merge the release PR into main.
- If there are conflicts in the changelog, make sure to place any new changelog entries at the top, above the section for the current release, as these new entries are not part of the current release and should be placed in the "unreleased" section.
- The release PR must be merged before pushing the tag to ensure that we always release a commit that is present on the main branch. It's not required that the commit is the head of the main branch, but there should be no chance of a future release accidentally not including changes from this release.
Push the new tag up:
```
git push origin refs/tags/v1.3.6
```
Find the Release workflow run that was just triggered by pushing the tag, and monitor the status of the release build.
- DO NOT approve the "publish" stages of the workflow yet.
Download the VSIX from the draft GitHub release at the top of the releases page that is created when the release build finishes.
Unzip the .vsix and inspect its package.json to make sure the version is what you expect, or look at the source if there's any doubt the right code is being shipped.
Install the .vsix file into your vscode IDE and ensure the extension can load properly. Run a single command (like run query, or add database).
Approve the deployments of the Release workflow run. This will automatically publish to Open VSX and VS Code Marketplace.
- If there is an authentication failure when publishing, be sure to check that the authentication keys haven't expired. See below.
Go to the draft GitHub release in the releases page, click 'Edit', add some summary description, and publish it.
Confirm the new release is marked as the latest release.
If documentation changes need to be published, notify documentation team that release has been made.
Review and merge the version bump PR that is automatically created by the Release workflow.

Secrets and authentication for publishing

Repository administrators will need to manage the authentication keys for publishing to the VS Code marketplace and Open VSX. Each requires an authentication token.

To regenerate the Open VSX token:

Log in to the user settings page on Open VSX.
Make sure you are a member of the GitHub namespace.
Go to the Access Tokens page and generate a new token.
Update the secret in the publish-open-vsx environment in the project settings.

Publishing to the VS Code Marketplace is done using a user-assigned managed identity and should not require the token to be manually updated.

6.0 KiB Raw Blame History

Releasing (write access required)

Secrets and authentication for publishing

6.0 KiB

Raw Blame History