fix(arcup): a release is newer than its own pre-release - #300
Conversation
version_gt strips the pre-release tag from both arguments before comparing,
so 0.3.0 and 0.3.0-rc.1 reduce to the same numbers, fall through every
comparison and reach the final `return 1`. SemVer orders a release above any
pre-release of the same version, so the answer should be true.
The effect is on anyone running a pre-release of the installer.
check_installer_up_to_date never tells them the release shipped, and
update_arcup refuses to move:
if ! version_gt "$remote_version" "$ARCUP_INSTALLER_VERSION"; then
so `arcup --self-update` from 0.3.0-rc.1 to 0.3.0 reports it is already
current. The existing tests cover the two cases that already worked and not
this one.
Keep the pre-release tags aside and, when major.minor.patch are equal, treat
an empty tag as the higher precedence. Ordering two pre-releases of the same
version is left alone, since no caller compares them.
Installer version bumped per the note at the top of the script.
romac
added
pending-import
|
The red Same test, same signal: which matches the report in #298 that the job is red on unrelated branches including This PR touches Worth noting alongside #248 — the arcup shell suite is not run in CI, so the two cases added here would not be exercised there either until that lands. |
|
Confirming the CI attribution from the #298 side (I filed the job-level history analysis there): the only failing check on this head is I also ran the parts your Windows checkout couldn't. On Linux at head Verification of the fix itself, from sourcing
And confirmed on the #248 point: no workflow references |
|
@JspIIV Thanks! Can you please merge latest |
…e-beats-prerelease
|
Done — Re-ran the shell suite on the merged head: The last two are the cases this PR adds; the first two are the ones that already passed. |
3 participants
What
version_gtdrops the pre-release tag from both arguments before it compares anything:So
0.3.0and0.3.0-rc.1both reduce to0.3.0, every major/minor/patch comparison falls through, and the function reaches its finalreturn 1. SemVer §11 puts a release above any pre-release of the same version, so this one should be true.Measured against the current script:
version_gt 0.3.1-rc.1 0.3.0version_gt 0.3.0-rc.1 0.3.0version_gt 0.3.0 0.3.0-rc.1version_gt 0.3.0 0.3.0-rc.2Why it matters
It affects anyone running a pre-release of the installer itself.
check_installer_up_to_datenever prints the "outdated" warning once the release ships, andupdate_arcuprefuses to move:so
arcup --self-updatefrom0.3.0-rc.1to0.3.0reports that it is already current. There is no way out of an rc build except reinstalling by hand.test_version_comparisoncovers the two cases that already worked and not this one, which is why it went unnoticed.Change
Keep the pre-release tags aside instead of discarding them, and when major/minor/patch are equal treat an empty tag as the higher precedence.
Ordering two pre-releases of the same version (
rc.2vsrc.10) is deliberately left alone — it needs the full SemVer identifier comparison and no caller does it, since arcup only ever compares against its own version. Happy to add it if you would rather have it complete.ARCUP_INSTALLER_VERSIONbumped to0.2.1, per the note at the top of the script.Tests
Two cases added to
test_version_comparison. Againstmainthe first one fails:With the change,
bash arcup/test_arcup.shpasses through toarchive path traversal fails.One note on running the suite locally:
test_archive_link_entries_failfails on a Windows checkout becauseln -sneeds privileges there. It fails the same way on an untouched tree, so it is unrelated to this change — I could not exercise that case or the two after it.Closes #205.