Project
cortex
Description
When running bump-version.sh patch (or minor/major) on a prerelease version like 1.0.0-beta.1, the script strips the prerelease suffix to get the base version 1.0.0, then increments from that base. This produces 1.0.1, completely skipping the stable 1.0.0 release. In standard semver tooling (npm, cargo-release, etc.), patch from a prerelease drops the suffix to produce the stable version (1.0.0), since the prerelease is preceding that stable release, not coming after it.
Error Message
No error — the script succeeds and writes the wrong version.
Debug Logs
# Current version is a prerelease:
$ cat VERSION_CLI
1.0.0-beta.1
$ ./scripts/bump-version.sh --dry-run patch
Current version: 1.0.0-beta.1
New version: 1.0.1 # BUG: should be 1.0.0
$ ./scripts/bump-version.sh --dry-run minor
Current version: 1.0.0-beta.1
New version: 1.1.0 # BUG: should be 1.0.0
$ ./scripts/bump-version.sh --dry-run major
Current version: 1.0.0-beta.1
New version: 2.0.0 # BUG: should be 1.0.0
System Information
File: scripts/bump-version.sh, lines 103-106, 136-145
Root cause: lines 103-106 strip prerelease and parse the base, then lines 136-145 always increment from the base without checking if a prerelease was present
Screenshots
No response
Steps to Reproduce
Set VERSION_CLI to 1.0.0-beta.1
Run ./scripts/bump-version.sh --dry-run patch
Observe output says New version: 1.0.1
Expected Behavior
Per semver convention (and consistent with npm, cargo-release, and other version management tools):
patch from 1.0.0-beta.1 → 1.0.0 (release the stable version the prerelease precedes)
minor from 1.0.0-beta.1 → 1.0.0 (same minor, just release stable)
major from 2.0.0-rc.1 → 2.0.0 (same major, just release stable)
patch from 1.0.0 (no prerelease) → 1.0.1 (normal increment)
The logic should be: if the current version has a prerelease suffix and the bump level matches or exceeds the prerelease level, drop the suffix; only increment if the current version is already stable.
Actual Behavior
Lines 103-106 strip the prerelease suffix unconditionally:
BASE_VERSION="${CURRENT_VERSION%%-*}" # 1.0.0-beta.1 → 1.0.0
IFS='.' read -r MAJOR MINOR PATCH <<< "$BASE_VERSION" # MAJOR=1, MINOR=0, PATCH=0
Then lines 136-145 always increment:
case $BUMP_TYPE in
patch)
NEW_VERSION="$MAJOR.$MINOR.$((PATCH + 1))" # 1.0.(0+1) = 1.0.1
;;
The prerelease suffix is discarded before incrementing, so the increment always starts from the base version and overshoots. Version 1.0.0 is never produced — it is permanently skipped if any 1.0.0-* prerelease was the current version.
Additional Context
This also means the compare_versions() function at lines 116-132 has a related flaw: it strips prerelease suffixes before comparing, so 1.0.0 and 1.0.0-beta.1 are treated as equal. Setting an exact version from 1.0.0 to 1.0.0-beta.1 (a semver downgrade — prereleases have lower precedence than their stable counterpart) produces no downgrade warning, because both have base 1.0.0 and compare as equal.
Project
cortex
Description
When running bump-version.sh patch (or minor/major) on a prerelease version like 1.0.0-beta.1, the script strips the prerelease suffix to get the base version 1.0.0, then increments from that base. This produces 1.0.1, completely skipping the stable 1.0.0 release. In standard semver tooling (npm, cargo-release, etc.), patch from a prerelease drops the suffix to produce the stable version (1.0.0), since the prerelease is preceding that stable release, not coming after it.
Error Message
Debug Logs
System Information
Screenshots
No response
Steps to Reproduce
Set VERSION_CLI to 1.0.0-beta.1
Run ./scripts/bump-version.sh --dry-run patch
Observe output says New version: 1.0.1
Expected Behavior
Per semver convention (and consistent with npm, cargo-release, and other version management tools):
patch from 1.0.0-beta.1 → 1.0.0 (release the stable version the prerelease precedes)
minor from 1.0.0-beta.1 → 1.0.0 (same minor, just release stable)
major from 2.0.0-rc.1 → 2.0.0 (same major, just release stable)
patch from 1.0.0 (no prerelease) → 1.0.1 (normal increment)
The logic should be: if the current version has a prerelease suffix and the bump level matches or exceeds the prerelease level, drop the suffix; only increment if the current version is already stable.
Actual Behavior
Lines 103-106 strip the prerelease suffix unconditionally:
BASE_VERSION="${CURRENT_VERSION%%-*}" # 1.0.0-beta.1 → 1.0.0
IFS='.' read -r MAJOR MINOR PATCH <<< "$BASE_VERSION" # MAJOR=1, MINOR=0, PATCH=0
Then lines 136-145 always increment:
case $BUMP_TYPE in
patch)
NEW_VERSION="$MAJOR.$MINOR.$((PATCH + 1))" # 1.0.(0+1) = 1.0.1
;;
The prerelease suffix is discarded before incrementing, so the increment always starts from the base version and overshoots. Version 1.0.0 is never produced — it is permanently skipped if any 1.0.0-* prerelease was the current version.
Additional Context
This also means the compare_versions() function at lines 116-132 has a related flaw: it strips prerelease suffixes before comparing, so 1.0.0 and 1.0.0-beta.1 are treated as equal. Setting an exact version from 1.0.0 to 1.0.0-beta.1 (a semver downgrade — prereleases have lower precedence than their stable counterpart) produces no downgrade warning, because both have base 1.0.0 and compare as equal.