Releasing

beta releases

beta releases are scheduled for the end of each sprint, and occasionally between a sprint.

Release process

To release a new version of Calcite Components you must:

1. Be a member of the @esri organization on npm.

2. Be a member of the admin team for Calcite Components.

3. Make sure you have a remote named origin pointing to Esri/calcite-components.

4. Ensure you have set up an access token (see below)

5. Run npm run release:prepare. This script will:

   • Create a build
   • Run all the tests
   • Update the package version
   • Create a changelog entry for the current release
   • Create a commit and tag it - ⚠️ Note if you need to make changes after this step, make sure to amend the commit (git commit --amend) and recreate the tag (git tag --force <version>)

6. Run npm run release:publish. This script will:

   • Push the release tag to the repo
   • Publish to NPM
   • Publish to GitHub (including source and package)

7. Run npm run release:docs to update the docs. This script will:

   • Create the component doc
   • Create the storybook build
   • Push all doc content to the gh-pages branch

   Note: this script can be run anytime the docs need to be updated

Setting up an access token for release

In order for the release script to work, you'll need to generate an access token with GitHub and export it into your shell environment as GH_RELEASE_GITHUB_API_TOKEN. First, generate a token, then copy that token and add it to your bash_profile (~/.bash_profile on Mac):

export GH_RELEASE_GITHUB_API_TOKEN=PASTE_TOKEN_HERE

You may need to start a new terminal window to apply the profile changes.

Deploying documentation

We deploy the docs with storybook deployer.

1. Make sure your changes have landed in master
2. Use npm run release:docs to build the docs and deploy to gh-pages

next releases

next releases are useful for testing incoming changes between releases. They are deployed by the CI and happen if changes between tagged releases (beta or next) have 'deployable' commits. A deployable commit is:

1. a commit of type feat or fix
2. a commit type that introduces a breaking change

Release process

In order to enable next releases, the NEXT_RELEASE_ENABLED GitHub Action secret needs to be a truthy value. This variable enables the deploy action to run after each successful build. When enabled, each deploy phase will run a script that runs to determine whether there are deployable commits after the last release. If this is the case, a calcite-components production build will be created, tagged and committed then pushed to the repository and then deployed to NPM.

Output targets and JSAPI CDN

See this internal doc

Bumping the examples

A GitHub Action will automatically bump the versions in calcite-components-examples and open a PR on Wednesday night after the release. While in beta, review/accept the PRs and test them locally every once in a while. Here is the script incase any changes are needed.