Support for canary releases based on changesets?

[dotansimha]

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

[emmatown]

This sounds like snapshot releases (or at least the intent behind them).

{plannedVersion}-canary.{COMMIT_ID}

Using plannedVersion instead of 0.0.0 can be done with ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.useCalculatedVersionForSnapshots though you can't currently use a commit.

@Andarist I'm kinda thinking we should have a "snapshot version template" config option,

So you could make have some variables that we provide like:

• tag
• commit
• timestamp
• plannedVersion (v not sure about this name)

and the default would be 0.0.0-{tag}-{timestamp} to align with the current behavior and you could express whatever and it would replace ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.useCalculatedVersionForSnapshots and #830.

Allowing non-ranged publishing

Snapshot releases should definitely use exact versions for dependencies (I'm surprised that's not already true tbh). Do you want to create a PR for that?

[dotansimha]

Oh, wow, I totally missed the snapshot release option.

I tested it now, and here are my thoughts:

1. This seems like a great solution for canary / alpha releases.
2. Using useCalculatedVersionForSnapshots seems to work great, I guess it's under experimental due to the template idea? (which I really prefer better over a boolean, this should make snapshot releases simpler to manage and customize).
3. A CHANGELOG file is created during the version execution - do you think it's valuable to allow to pass --no-changelog to version command in order to avoid it? (due to the temporary nature of these releases, I don't think we need a CHANGELOG record?)
4. The version used in nested dependencies is not exact, just confirmed it be making 2 packages with dependencies and ran version command:

I can open the following PRs:

1. Drop useCalculatedVersionForSnapshots and support for snapshotVersionTemplate: string with the placeholders you mentioned.
2. Fix the dependencies versioning and make sure it's always pinned.
3. Should I create another PR for adding --no-changelog?

Does it make sense?

Thanks @mitchellhamilton

[dotansimha]

@mitchellhamilton I created a PR to fix the exact versioning when snapshot release is performed: #857

[dotansimha]

@mitchellhamilton Created another PR for adding snapshotVersionTemplate and drop the useCalculatedVersionForSnapshots flag: #858

[Andarist]

A CHANGELOG file is created during the version execution - do you think it's valuable to allow to pass --no-changelog to version command in order to avoid it? (due to the temporary nature of these releases, I don't think we need a CHANGELOG record?)

Are there any downsides to updating CHANGELOGs there? You are not supposed to commit the output of a snapshot release anyway.

[dotansimha]

Are there any downsides to updating CHANGELOGs there? You are not supposed to commit the output of a snapshot release anyway.

Yeah, not committing it, just noticed it's generated anyway (while testing locally). I guess it's very minor :)

[Andarist]

It might actually be somewhat nice to have those generated because you might always easily check in the package itself what kind of a change has been published in a given snapshot release.