Releasing

Releasing

major/minor/patch releases

When performing a scheduled release, first check in with Franco (or Matt if Franco isn't available) and Kitty to see if there are any pull requests that need to be merged before releasing. Once they say we are ready for release, follow the steps below. If you run into errors or other issues during the release steps, you can reach out to Ben for help (or Franco if Ben isn't available).

Prevent merging PRs

When releasing during normal work hours, you should block people from merging PRs while you're releasing. To "block" PRs do the following (requires admin privilege):

1. Let the team know via Teams in the Core - Releases 🔒 channel (@ the channel for visibility)

2. Go to the repo settings -> "Branches"

3. Under "Branch protection rules" edit the entry for main

4. Under "Require approvals" change the number from 1 to 6 and save the changes.

   

Release steps

To release a of Calcite Components you must be a member of the admin team for Calcite Components. Then follow these steps

1. Review the PR created by release-please (titled "chore: release main") to make sure the changelog(s) and package versioning looks correct

2. add the skip visual snapshots label

3. Make sure rest of the PR checks are passing, specifically e2e tests

4. Approve and install the PR (you will need to use Admin privilege to override the 6 approval rule added above)

5. Wait for the release's Deploy Latest action to finish.

6. Ensure the released package(s) were deployed to NPM and that GitHub Releases were created

   • You can check the NPM version on the website or on the CLI with:

     npm view @esri/calcite-components version

7. Reach out to Ben for investigation if something went wrong (this is unlikely now that everything is completely automated)

8. Change the main branch's required approvals back to 1 and save the changes (see the section above)

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. Make sure to test the samples when there are major changes. Here is the script if any changes are needed.

next releases

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

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

next releases should be fully automated by CI. If you need to disable next releases, you can do so by setting the NEXT_RELEASE_ENABLED GitHub Secret to anything but true. If you need to manually release next, you can run the following commands from the root directory:

npm run clean
npm install
npm test
npm run version:next
# verify the changelog and package versions look correct
npm run publish:next
npm run util:push-tags

NOTE: If need to change anything after running version:next, make sure to amend the previous commit and recreate all of the tags before continuing.

Release patches and regressions

The following are best practices for limiting regressions and releasing patches when necessary.

Prior to release

• When installing big items, author(s) should post in the internal channel (Core - Releases 🔒) and public channel (Calcite Components) to keep an eye out for issues related to the changes. This should happen after the item's PR is merged and next is deployed so users can start testing early.

Patching

• The soonest a patch can occur after a release is one week. This is to allow enough time for users to find any other regressions so that we don't need to release multiple patches.
• Once we decide a patch is needed, notify the public channel (Calcite Components) about the known issues and plans for an incoming patch.
• Inform the team in the internal release channel to hold off on risky installs, revert any that landed, and to (re)install after the patch.
• Check-in daily with the team in the internal release channel about known issues, reported regressions, and fix statuses.
• Remind the team two days before and the day of the scheduled patch to make sure everything is included.