Release process

Prepare the release commit

Ensure all relevant PRs have merged to master.
Create release branch based off latest master. 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]
```
Compile the monorepo with yarn compile-libs.
Compile the publishable distributions with yarn dist.
Update the root package.json version (match core's version, or bump a patch version if core wasn't changed).

Review and commit the changes.

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

Create a PR on GitHub. Write the release notes in the description.
This PR must change the contents of the docs/ folder, or it will fail. This folder should contain the latest documentation site which will be available at http://blueprintjs.com/docs.
Perform regression pass on the release artifacts.
Merge the release PR!
At this point, the site has been updated since it uses the contents of the docs/ folder.

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

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.

Run lerna publish --skip-npm --scope '@blueprintjs/{core,datetime,labs,table}' (or some appropriate subset of the packages).
Interactively pick version numbers.
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).