Benjamin Taylor bee19e78df fix(release): make canary publishes reachable and cross-scope composable ...

Two release-tooling defects turned a pair of canary publishes into a broken
combination for consumers (a canary runtime resolving the last STABLE
channels-intelligence, which still called the removed `channel.addAdapter`).

1. Canary versions were prereleases of an ALREADY-PUBLISHED version. A stable
   release leaves the working tree on the version it just published, and
   computePrereleaseVersion appended `-canary.<id>` to exactly that, so the
   canary sorted BELOW its own release (`0.2.1-canary.x < 0.2.1`): the `canary`
   dist-tag pointed behind `latest`, and no dependent range could ever resolve
   it. Base the canary on the next unreleased version instead (patch bump,
   reusing computeNextStableVersion's prerelease rule).

2. A canary published one scope at a time, but the scopes are only independent
   on the version axis. `@copilotkit/runtime` carries
   `"@copilotkit/channels-intelligence": "workspace:*"`, and `pnpm pack`
   resolves that against the working tree — so a `monorepo` canary pinned the
   channels family to its last stable release even when the commit changed both
   sides of the contract. Add a prerelease-only `all` selector that bumps and
   publishes every scope from one commit under one shared canary id, and warn
   loudly when a single-scope canary leaves a cross-scope pin behind.

`all` is a selector, never a scope: stable releases stay single-scope (their
tag, release branch, and npm/Slack links all derive from one scope name), which
publish-release.yml enforces in both jobs and the dropdown guard enforces per
workflow.

2026-07-24 15:53:13 -05:00

2.2 KiB

Raw Permalink Blame History

View Raw