Hi there!

We at The Guild are working with changesets extensively. One of the solution we implement on top of the current implementation of changesets is the ability to easily connect canary/alpha releases, based on active changesets.

To do that, we are applying a minimal patch file to changesets code, in order to allow flexibility in the release flow.

I'm sharing an overview of the technical changes we are doing today, and I can also create a PR if this makes sense. I was thinking of a workflow of changesets version canary in the CLI.

The canary / alpha workflows

1. To release a canary based on changesets, we are scanning and reading all relevant changesets that are currently available in the repo.
2. Then, we run assembleReleasePlan and builds the complete plan as changesets plan to release it (on the next release planned)
3. Then, we modify the version to be {plannedVersion}-canary.{COMMIT_ID}
4. Run applyReleasePlan to apply the change temporarily
5. Run changesets publishing script with --tag canary

Here's the script we are using: https://github.com/B2o5T/graphql-eslint/blob/master/scripts/canary-release.ts

This way - changesets are used as the source of truth to the packages that actually was changed and needs to be released - and we apply an empheral change to the versioning before publishing it to npm.

Allowing non-ranged publishing

As part of the canary release workflows, we want to make sure to get rid of all possible ranges (^ / ~) in the internal packages dependencies, to make sure to get the exact versions of the canary changes.

To do that, we added a new argument to versionPackage function, called ignoreRange

Reference: https://github.com/B2o5T/graphql-eslint/blob/master/patches/%40changesets%2Bapply-release-plan%2B6.0.0.patch#L19