Skip to content

Conversation

@mcmire
Copy link
Contributor

@mcmire mcmire commented Jul 9, 2025

If a commit is pushed which rolls back a release candidate and hence downgrades the version of the package in question, then this action will regard it as a release commit. Now, this doesn't affect core (e.g. https://github.com/MetaMask/core/actions/runs/16173551572/job/45653343692) because we also pass a commit message prefix, and release rollbacks don't follow that pattern, so they get rejected by this action.

However, we may actually want to know about release rollbacks. For instance, it would be useful to automatically remove the GitHub release/tag if a release is rolled back, or verify that the version being rolled back is also removed from the changelog. We can't do this well right now without repeating logic.

Therefore, this commit adds a new output, COMMIT_TYPE, which can either be release, release-rollback, or "normal" (not a release or a release rollback). In fact, this commit promotes this output as the one to use in the README and deprecates IS_RELEASE.

Closes #1.

If a commit is pushed which rolls back a release candidate and hence
downgrades the version of the package in question, then this action will
regard it as a release commit. This isn't right, and we should do
something about it.

However, we don't simply want to ignore this information, because it
may come in handy (for instance, if we want to automatically remove the
GitHub release/tag or verify the changelog in a different way).

Therefore, this commit adds a new output, `COMMIT_TYPE`, which can
either be `release`, `release-rollback`, or unset (not a release or a
release rollback). In fact, this commit makes this output recommended
and deprecates `IS_RELEASE`.
cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Semver Prerelease Parsing Fails

The semver comparison script incorrectly handles prerelease versions that contain dots (e.g., "1.0.0-alpha.1"). It splits the full version string by dots before extracting the prerelease, causing parts of the prerelease identifier (like the '1' in 'alpha.1') to be incorrectly parsed as numeric version components. This leads to erroneous version comparisons.

scripts/compare-semver-versions.sh#L9-L30

# Split versions into major.minor.patch and prerelease
IFS='.' read -a v1_parts <<< "$version1"
IFS='.' read -a v2_parts <<< "$version2"
# Extract prerelease parts if they exist
local v1_prerelease=""
local v2_prerelease=""
# Check if version1 has prerelease (contains hyphen)
if [[ "$version1" == *"-"* ]]; then
v1_prerelease="${version1#*-}"
# Remove prerelease from parts array
v1_parts=("${v1_parts[@]%-*}")
fi
# Check if version2 has prerelease (contains hyphen)
if [[ "$version2" == *"-"* ]]; then
v2_prerelease="${version2#*-}"
# Remove prerelease from parts array
v2_parts=("${v2_parts[@]%-*}")
fi

Fix in CursorFix in Web


Was this report helpful? Give feedback by reacting with 👍 or 👎

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.

Check if the version is incremented, not just changed?

2 participants