Discovered while building the v2.1.0 milestone-merge resolution branch (#1901).
What
After resolving the merge, .github/workflows/main.yml is the only file where the merged tree differs from v2/main — main carries 38 lines v2/main has never had:
| Commit |
Change |
| #1831 |
least-privilege default permissions: contents: read for GITHUB_TOKEN |
| #1834 |
derive the npm dist-tag from the version, so a prerelease can't publish to latest |
| #1836 |
publish via npm OIDC trusted publishing (id-token: write + environment: release), removing the NODE_AUTH_TOKEN/NPM_TOKEN path that doesn't exist in this repo |
Those landed on main during the 2.0.0 rc series and were never brought back to v2/main. They auto-merged cleanly into the resolution branch, so the v2.1.0 release is not at risk — main keeps them.
Why it still matters
v2/main is the develop branch, so its copy of the release workflow is the one every future PR edits. Today that copy:
- publishes with
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} against a secret the repo does not have, and
- has no dist-tag derivation, so publishing a
-rc from it would point latest at a release candidate.
Nothing breaks while releases are cut from main — but the divergence is a live trap: anyone editing workflows on v2/main works from the stale version, and a future change could silently regress main back to it. This is also the only content main has that v2/main lacks, so closing it makes the two branches identical outside the merge lineage.
Suggested fix
Port the three changes onto v2/main (a plain forward-port of the workflow hunks — not a back-merge of main, per the #1868 reasoning). Afterward, git diff origin/main origin/v2/main over .github/ should be empty.
Related
Discovered while building the v2.1.0 milestone-merge resolution branch (#1901).
What
After resolving the merge,
.github/workflows/main.ymlis the only file where the merged tree differs fromv2/main—maincarries 38 linesv2/mainhas never had:permissions: contents: readforGITHUB_TOKENlatestid-token: write+environment: release), removing theNODE_AUTH_TOKEN/NPM_TOKENpath that doesn't exist in this repoThose landed on
mainduring the 2.0.0 rc series and were never brought back tov2/main. They auto-merged cleanly into the resolution branch, so the v2.1.0 release is not at risk —mainkeeps them.Why it still matters
v2/mainis the develop branch, so its copy of the release workflow is the one every future PR edits. Today that copy:NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}against a secret the repo does not have, and-rcfrom it would pointlatestat a release candidate.Nothing breaks while releases are cut from
main— but the divergence is a live trap: anyone editing workflows onv2/mainworks from the stale version, and a future change could silently regressmainback to it. This is also the only contentmainhas thatv2/mainlacks, so closing it makes the two branches identical outside the merge lineage.Suggested fix
Port the three changes onto
v2/main(a plain forward-port of the workflow hunks — not a back-merge ofmain, per the #1868 reasoning). Afterward,git diff origin/main origin/v2/mainover.github/should be empty.Related