Skip to content
This repository was archived by the owner on Oct 1, 2024. It is now read-only.

Release process

Jump to bottom
Ben McMorran edited this page Feb 24, 2023 · 7 revisions

Production releases are represented by tags on the main branch. Every production release should be preceded by one or more automated nightly pre-releases. Because VS Code follows the Modern Lifecycle Policy, old releases of the extension do not need to be serviced, so there's no need to maintain a separate release branch. Follow these steps to create a new release candidate or production release.

Automated nightly pre-releases

Every night, if there have been changes on the main branch, an Azure DevOps pipeline will automatically build the extension and publish it to the VS Code Marketplace as a pre-release. The pre-release version number is based on current release number but has a date-based patch version of the form YYMMDDRRR where RRR is a number that increments if there are multiple pre-releases in the same day.

  1. Run npm install from the root of the repository.
  2. Update CHANGELOG.md to describe the changes in the new release.
  3. Commit the changes directly to main and push.
git add package.json package-lock.json CHANGELOG.md
git commit -m "Pre-release v0.5.0"
git push
  1. Tag the release candidate with a tag that matches the new version and push the tag.
git tag v0.5.0-rc
git push origin v0.5.0-rc
  1. Verify that an Azure DevOps CI build associated with the tag has started. If the build fails (unlikely because there are no changes aside from version number), investigate the failure and open PRs to fix any issues.
  2. Once the build finishes, verify that the release candidate appears on GitHub.
  3. Install the release candidate VSIX in VS Code and validate that all issues labeled fixed-pending-release have been resolved. For higher risk releases, you may also want to share the VSIX with partners for testing.

Production release

  1. On the main branch, update the version in package.json. For example, "version": "0.5.0". For better or worse, vscode-arduino is effectively following ZeroVer.
    1. Major (first) version is always zero.
    2. Minor (second) version is incremented for each production release.
    3. Patch (third) version is always zero for production releases. Non-zero patch versions are reserved for pre-releases.
  2. Run npm install from the root of the repository.
  3. Update the release date and notes in CHANGELOG.md.
  4. Commit the changes directly to main and push.
git add package.json package-lock.json CHANGELOG.md
git commit -m "Bump to v0.5.0"
git push
  1. Tag the release with a tag that matches the new version and push the tag.
git tag v0.5.0
git push origin v0.5.0
  1. Verify that an Azure DevOps CI build associated with the tag has started.
  2. Once the build finishes, verify that the release appears on GitHub.
  3. Download the release VSIX and upload it to the VS Code Marketplace extension portal.
  4. Once the Marketplace finishes validation steps, verify that you can install the new version of vscode-arduino from the Marketplace within VS Code.
  5. Verify that all issues labeled fixed-pending-release are closed. There are some issues with this automation that we haven't fully flushed out yet.
Clone this wiki locally