Maintenance·Pushed May 4, 2026·S

Release pipeline un-stuck after tag collision

A misconfigured version pin in the release automation caused a duplicate tag collision, wedging the release pipeline. The fix removes the pin and reverts partial version bumps so release-please can retry cleanly.

The release-please automation got stuck after merging PR #27. A version pin in the root package's release config, combined with the linked-versions plugin, forced both packages to target the same v0.1.0 tag that already existed. The release attempt failed partway through—GitHub release creation and npm publish never happened, but the manifest file was partially bumped, leaving the codebase in an inconsistent state. The fix strips out the offending configuration and reverses the half-applied changes. The version pin is removed from the release config. The CLI package's version, the manifest file, and the changelog headers are all reverted to 0.1.0. The incorrectly generated CLI changelog is deleted entirely. With these changes in place, the next push will let release-please compute the release fresh. Both packages will target 0.1.1, the v0.1.1 tag is new, and the publish pipeline should run end-to-end.

Technical description

A broken release-please run left the repository in an inconsistent state. After merging PR #27, the automation attempted to create a release but failed due to a duplicate tag collision. The root package's "release-as": "0.1.0" pin, when combined with the linked-versions plugin, caused both the root package and the CLI package to target the same v0.1.0 tag—one that already existed from a prior manual release. The GitHub release creation failed, no v0.1.1 tag was created, and no npm publish occurred. However, the manifest file was partially updated to cli: 0.1.1, and the PR label flipped to autorelease: tagged. This commit rolls back the half-applied state by reverting version numbers, removing incorrect changelog entries, and deleting the problematic configuration. In [[code ref=3]]release-please-config.json[[/code]], the "release-as": "0.1.0" pin is removed from the root package's configuration. This was the root cause of the collision. [````json file=release-please-config.json ".". { - "release-as": "0.1.0" } [ ````] The [[code ref=2]]cli/package.json[[/code]] version is reverted from 0.1.1 back to 0.1.0, and the [[code ref=1]].release-please-manifest.json[[/code]] is updated to match. [````json file=.release-please-manifest.json - "cli": "0.1.1" + "cli": "0.1.0" [ ````] The [[code ref=4]]cli/CHANGELOG.md[[/code]] file is deleted entirely—it contained a 0.1.1 entry that never shipped and release-please will recreate it on the next release. The duplicate 0.1.0 release header in [[code ref=5]]CHANGELOG.md[[/code]] is also removed, along with its associated broken compare link. These changes put the repository back into a clean state. The next push will trigger release-please fresh. With the pin gone and linked-versions plugin active, both packages will compute to 0.1.1. The v0.1.1 tag will be new, and the publish-cli OIDC pipeline should complete end-to-end. **Files at a Glance:** - [[code]].release-please-manifest.json[[/code]] — reverted cli version to 0.1.0 - [[code]]cli/package.json[[/code]] — reverted version to 0.1.0 - [[code]]release-please-config.json[[/code]] — removed "release-as" pin from root package - [[code]]cli/CHANGELOG.md[[/code]] — deleted (will be regenerated) - [[code]]CHANGELOG.md[[/code]] — removed duplicate 0.1.0 header