Release process

Prepare the release commit

1. Ensure all relevant PRs have merged to develop.

2. Create release branch based off latest develop. Use SemVer to come up with the next version number: [major].[minor].[patch] (all three numbers are required).

   git checkout master
   git pull
   git checkout -b release/[version number]
   

3. Compile the monorepo with yarn compile.

4. Compile the publishable distributions and copy over artifacts to the (git-ignored) docs/ folder with yarn dist.

5. Update the root package.json version (match core's version, or bump a patch version if core wasn't changed).

6. Review and commit the changes.

   git commit -a -m "Prepare release v[version number]"
   

Review the release PR

1. Create a PR on GitHub. Write the release notes in the description.
2. Perform regression pass on the release preview artifacts.
3. Merge the release PR.
4. With the latest docs built locally (yarn dist), run yarn deploy to push changes to the live site hosted on the master branch.

Making a 1.x release

The main branch of this repository contains 2.x code. Making a 1.x release is similar to the process above (target release/1.x instead of develop), but the docs deployment part is different:

• Build the 1.x docs with yarn dist on release/1.x.
  • Make sure you have the right node_modules and have run yarn clean at the root to avoid picking up any 2.x built assets).
• Copy the git-ignored docs/docs/ (note the nested folder path!) folder outside the repo.
• Switch to develop, start a new branch.
• Paste the contents of the folder you just copied into docs-static/docs/v1/. Replace all existing contents of the folder (there will be old files with md5-hashed names that are now dead code).
• Make a PR against develop with the changes to the static assets you just made.

Writing release notes

See other releases for example format. We typically describe changes using the following groups:

1. 🔥 BREAKING
2. NEW
3. Fixed
4. Changed
5. Deprecated

A 🌟 is used to indicate release highlights: features or fixes of particular note.

A useful way to determine exactly what happened in a release is to diff the commits with the previous version or use the relevant milestone.

Publish to NPM

1. Run lerna publish --skip-npm --scope '@blueprintjs/{core,datetime,labs,table}' (or some appropriate subset of the packages).
2. Interactively pick version numbers.
3. Review the commit which Lerna just produced.
   • Manually audit the dependencies between packages. This is an important step as not all packages need to depend on the latest version of the core package.
   • ⚠️ Lerna updates transitive package dependencies, so you'll need to revert those changes (unless datetime does actually require the latest version of core, for instance).
4. Push to master with tags: git push origin master --follow-tags.
5. Attach release notes to the new tags which were produced in the Github UI.