-
Get the latest published stable tag from origin (across any major version):
git ls-remote --tags --sort=-v:refname origin "v*" | grep -E 'refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1 | sed 's|.*refs/tags/v||'
The output is <PREV_TAG> (e.g., 2.10.4). The v is added back wherever a tag form is needed (v<PREV_TAG>). The grep filter ensures only stable tags are considered (excludes -beta, -rc, etc.). The version-aware sort returns the highest stable version regardless of major.
If the command returns nothing (the repository has no stable tags at all), stop and ask the user to pass a starting version explicitly. Do not guess.
-
Check if local has a newer stable tag that hasn't been published:
git tag --list "v*" --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1 | sed 's/^v//'
If this output differs from <PREV_TAG> (i.e., local has a newer tag than origin), show both to the user and ask which to use as the previous tag. Wait for explicit confirmation before continuing.
-
Gather and classify the changes since <PREV_TAG>. Get the commit list:
git log v<PREV_TAG>..main --oneline
For each PR referenced in the commit list (the (#NNN) suffix), fetch the full description:
gh pr view <PR-NUM>
Classify each change and write the bullets following references/RELEASE_NOTES_STYLE_GUIDE.md. The style guide defines the section names, bullet structure, voice, capitalization, and formatting conventions — apply them as written. Do not invent changes that aren't supported by the PRs. Consolidate overlapping PRs into a single bullet.
-
Compute <RECOMMENDED_VERSION> from the classified content using these rules:
- Patch: the consumer does not need to change their code. Includes new components, features, hooks, icons, and fixes — anything that doesn't break or alter existing usage. Bump patch (e.g.,
3.0.3 → 3.0.4).
- Minor: existing consumer code still works, but the consumer must update their usage to benefit from refactors or API/design changes. Bump minor, reset patch (e.g.,
3.0.3 → 3.1.0).
- Major: existing consumer code will break — migration required (breaking changes, removed or renamed APIs). Bump major, reset minor and patch (e.g.,
3.0.3 → 4.0.0).
-
Determine <VERSION>:
- If the user passed a full semver like
3.0.4, use it as-is.
- If the user passed a partial semver, fill in zeros for the missing parts (e.g.,
3.1 → 3.1.0, 3 → 3.0.0).
- If the user passed a keyword (
patch, minor, major), apply that bump to <PREV_TAG>.
- Otherwise, use
<RECOMMENDED_VERSION>.
-
Compute <BUMP_TYPE> from how <VERSION> differs from <PREV_TAG>:
major if the major number changed (e.g., 3.0.3 → 4.0.0).minor if only the minor number changed (e.g., 3.0.3 → 3.1.0).patch if only the patch number changed (e.g., 3.0.3 → 3.0.4).
-
Verify the target tag and release branch don't already exist:
git tag -l "v<VERSION>"
git branch --list "release/v<VERSION>"
git ls-remote --heads origin "release/v<VERSION>"
Stop if any command produces output:
- First: tag
v<VERSION> already exists.
- Second: local branch
release/v<VERSION> already exists.
- Third: remote branch
release/v<VERSION> already exists.
-
Save the classified content to a release notes file. Compute today's date and write the file:
date +%Y%m%d
Save to release_scorer-ui-kit_<TODAY>.md at the project root. The file's structure, section names, and formatting are defined in references/RELEASE_NOTES_STYLE_GUIDE.md. Follow that guide.
-
Show the user the resolved values and the path to the release notes draft:
Target version: <VERSION>
Previous tag: v<PREV_TAG>
Bump type: <BUMP_TYPE>
Recommended version: <RECOMMENDED_VERSION>
Release branch: release/v<VERSION>
Release notes draft: ./release_scorer-ui-kit_<TODAY>.md
Always show Recommended version even if it matches Target version — for transparency. If <VERSION> differs from <RECOMMENDED_VERSION>, also state the reason briefly (e.g., "user requested minor; analysis suggests major because of removed API in #631").
Wait for explicit confirmation before continuing to step 3. The user may edit the release notes file or override the version. (If the version is overridden, no file update is needed — the file no longer contains the version.)
