chore: maintain 0.1 on release/0.1 and publish its patches under release-0.1 - #56
Merged
Merged
Conversation
…ase-0.1 main moved to 0.2, but apps still on 0.1 need fixes. The publish workflow picked the dist-tag from the version alone (prerelease -> next), so a 0.1 hotfix released as-is would have pulled `next` back from 0.2 to 0.1. scripts/dist-tag.mjs now compares the version with main's: main's line publishes under next/latest as before, an older line under release-<line>, and a line ahead of main is refused. Both publish jobs use it, and CI also runs on pushes to release/** branches. README gains a Versions section (0.2 on main via @next, 0.1 on release/0.1 via @release-0.1) and its Install line names @next, since latest still points at 0.1 until 0.2.0. CONTRIBUTING documents cutting a release branch, fixing, versioning, releasing and recording an older line's patch.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Independent mutable-main lookups can assign inconsistent dist-tags across registries, and one release instruction overstates validation.
Review effort: Balanced
Findings: 1
Open (2)
What changed in this PR
Adds safe npm dist-tag routing for maintained release lines.
Changes:
- Adds and tests release-line dist-tag selection.
- Updates publishing and release-branch CI workflows.
- Documents 0.1 maintenance and release procedures.
| File | Description |
|---|---|
scripts/dist-tag.mjs |
Implements dist-tag selection. |
scripts/dist-tag.d.mts |
Declares script types. |
src/distTag.test.ts |
Tests release routing. |
.github/workflows/publish.yml |
Uses dynamic dist-tags. |
.github/workflows/ci.yml |
Enables release-branch CI. |
README.md |
Documents supported versions. |
CONTRIBUTING.md |
Documents maintenance releases. |
CHANGELOG.md |
Records the policy change. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Address ready-gate review: a separate dist-tag job reads main once and both publish jobs take its outputs, so the two registries cannot disagree if main moves to a new line between them. The documented gh release command no longer uses a <placeholder> the shell reads as redirection.
Member
Author
Ready-gate agent review (Opus) — blocking issues onlyNO BLOCKING ISSUES (reviewed at Copilot: reviewed — its findings were fixed in |
yomybaby
marked this pull request as ready for review
October 2, 2026 06:26
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
mainmoved to 0.2, but apps still on 0.1 need hotfixes and patch releases. Today the publish workflow picks the dist-tag from the version alone (prerelease →next), so a 0.1 hotfix released as-is would pullnextback from0.2.0-alpha.15to 0.1.scripts/dist-tag.mjs(+src/distTag.test.ts): compares the version being published withmain'spackage.json.next(prerelease) /latest(plain), unchanged behaviourrelease-<line>(e.g.release-0.1); never touchesnext/latestrelease-0.1is not a valid semver range, so npm accepts it as a dist-tag (0.1would be rejected)publish.yml: both jobs use the script (fetchesorigin mainto read its version).ci.yml: also runs on pushes torelease/**.mainvia@next, 0.1 onrelease/0.1via@release-0.1, where 0.1 fixes go). Install now names@next—lateststill points at0.1.0-alpha.23, so the bare command installed 0.1.gh release create --target release/0.1 --prerelease --latest=false, dist-tag check, recording the entry on main).The
release/0.1branch exists (cut fromv0.1.0-alpha.23). Since a release runs the workflow from the tagged commit, the branch gets the same rule in its own PR: #55.0.1 patch versioning: 0.1 never had a plain release, so patches continue
0.1.0-alpha.24, … which^0.1.0-alpha.Nranges already accept. A line with a plain release patches as0.2.1.Verification
pnpm run verify— passes (typecheck, lint, format, boundary, theme, test, build, pack, integration)node scripts/dist-tag.mjs 0.1.0-alpha.24 0.2.0-alpha.15→release-0.1;0.2.0-alpha.16 0.2.0-alpha.15→next