Skip to content

fix: correct release-type mapping and bump from the registry - #279

Merged
mcarey1590 merged 1 commit into
mainfrom
forks/mcarey/fix-release-version-mapping
Sep 21, 2026
Merged

mcarey1590 merged 1 commit into
mainfrom
forks/mcarey/fix-release-version-mapping

Conversation

@mcarey1590

Copy link
Copy Markdown
Contributor

What changed

.github/scripts/pub.sh, two independent bugs in the release path.

1. The release-type mapping was inverted

local release_type="minor"
if [[ "$1" == *"feat"* ]]; then
  release_type="major"
elif [[ "$1" == *"fix"* || "$1" == *"docs"* || "$1" == *"chore"* ]]; then
  release_type="patch"
fi

feat cut a major. minor was unreachable from any conventional prefix — it was only the fallback for a subject matching nothing. The match was also an unanchored substring over the entire subject, so anything containing the letters feat cut a major:

Subject Before After
feat: add an option major minor
fix: add feature flag major patch
chore: document new features major patch
fix: sync published version (#244) patch patch
feat!: drop node 20 major major
fix(api)!: rename export patch major
Merge pull request #278 from ... minor patch

Now: anchored prefixes, feat to minor, ! or BREAKING CHANGE to major, everything else to patch. An unrecognised subject no longer silently widens the version.

2. The bump was computed from a file that drifts

npm version read the checked-in package.json. The Release [skip-ci] commit-back is best effort and has fallen behind — the last one landed in 2022:

npm latest 1.7.4
main libs/web-socket-client/package.json 1.7.3

So the next patch release would compute 1.7.3 to 1.7.4 and fail as a duplicate publish. #244 papered over this by hand-syncing the version; it drifted again on the very next release.

The script now seeds from npm view <pkg> version before bumping, so the commit-back drifting is harmless instead of load-bearing. If the package is unpublished, it falls back to the checked-in version.

How to test

The mapping is a pure function, so it can be exercised directly:

bash -c 'source <(sed -n "/^getBuildType()/,/^}/p" .github/scripts/pub.sh); getBuildType "feat: add an option"'

I ran the full table above against both the old and new implementations; every row matches the After column, and the three regression rows reproduce under the old one. bash -n is clean.

For an end-to-end rehearsal without publishing:

DRY_RUN=True ./.github/scripts/pub.sh

Notes for reviewers

  • This commit is fix:, so under the corrected mapping it releases itself as a patch: 1.7.4 to 1.7.5. The workflow checks out the merge commit, so the new script governs its own release.
  • README's Publishing section was circular ("See the Publishing section above" from inside that section) and told readers to keep the version in package.json correct, which is the opposite of what the automation wants. Replaced with the actual CI behaviour and the subject-to-release table.
  • Depends on nothing. feat: make withCredentials configurable on the connection builder #278 should land after this so it cuts a 1.8.0 rather than a 2.0.0.

🤖 Generated with Claude Code

getBuildType inverted the conventional-commit convention: feat cut a
major and everything else a patch, leaving minor reachable only by a
subject that matched no prefix at all. The match was also an unanchored
substring over the whole subject, so "fix: add feature flag" and
"chore: document new features" both cut majors because they contain
"feat", and a plain merge commit cut a minor.

Anchor the prefixes, map feat to minor, honour the "!" and
"BREAKING CHANGE" markers for major, and default to patch so a subject
that does not declare its intent cannot widen the version.

Separately, npm version computed the next version from the checked-in
package.json. The "Release [skip-ci]" commit-back is best effort and has
drifted: main carries 1.7.3 while the registry serves 1.7.4, so the next
patch release would recompute 1.7.4 and fail as a duplicate. Seed the
version from the registry before bumping, which makes the commit-back
drifting harmless rather than load-bearing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mcarey1590
mcarey1590 merged commit 881ca6a into main Sep 21, 2026
1 check passed
@mcarey1590
mcarey1590 deleted the forks/mcarey/fix-release-version-mapping branch September 21, 2026 19:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants