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. |
|
The direction is right for #205's headline case ( After cores match, the new branch only special-cases "stable vs any prerelease". Two prereleases of the same core still fall through to version_gt "0.3.0-rc.2" "0.3.0-rc.1" # still false — #205 explicitly expects true
version_gt "1.0.0-beta.11" "1.0.0-beta.2" # still false#205's expected behaviour and checklist both require SemVer §11 identifier ordering, not only "release beats its own RC". Also overlaps with #212, which already implements full §11 precedence (build-metadata strip, numeric vs alphanumeric identifiers, dedicated The |
|
@kutluhaneth46 Your behavioural claim is correct — I executed all three implementations rather than reading them, and the gap is exactly where you say it is:
And #205 does ask for those rows explicitly — both its "Example expected comparisons" block and its Tests checklist list Three things I'd check before acting on the close #300 in favour of #212 part, though. 1. #212 does not carry the version bumpYou correctly flagged the Closing #300 for #212 as it stands would land the more complete algorithm behind a version number that self-update can't act on — the exact failure the bump exists to prevent. #212 needs the bump added before it substitutes for #300. 2. The two PRs conflict, so "if this lands first" is a rebase questionA real trial merge of #300 into #212 gives 3. Relative state of the two PRs#212 was last touched 2026-07-27 (head On reachability — correcting myselfEarlier in this thread I wrote that full identifier ordering "has no caller today." That was right by accident, and the reasoning behind it deserves tightening, because it bears on how urgent your point is. Both call sites compare ARCUP_BIN_URL="https://raw.githubusercontent.com/circlefin/arc-node/main/arcup/arcup"That's raw But that's a property of convention, not of construction. The accepted version regex explicitly permits prerelease suffixes ( Suggested pathRather than closing #300, the lowest-friction resolution is probably for it to expand to full §11 — @JspIIV already offered exactly that ("Happy to add it if you would rather have it complete"), it already has the bump and maintainer momentum, and #212's implementation is available to borrow from with credit. The alternative — land #212 plus the version bump and close #300 — is equally fine, but it's strictly more work than it looks, not less. One CI wrinkle either wayPer #248, no workflow under All version comparisons above were executed on Linux against each branch's actual |
…e-beats-prerelease
Two pre-releases of one major.minor.patch fell through to "not newer", so 0.3.0-rc.2 was not an update over 0.3.0-rc.1. circlefin#205 asks for both that and the release-over-pre-release case; the previous commit covered only the latter. prerelease_gt walks the dot-separated identifiers the way SemVer 11.4 describes: numeric ones compare as numbers so rc.11 outranks rc.2, a numeric identifier ranks below an alphanumeric one, alphanumeric ones compare byte-wise under LC_ALL=C so the locale cannot decide whether beta sorts above alpha, and with every shared identifier equal the shorter list ranks lower. Build metadata is stripped before anything else. It never affects precedence, and because it may contain '-' it had to go before the pre-release split -- on main, 1.0.0+build.9 reached the numeric compare as a patch of "0+build.9" and errored out. The tests walk the precedence chain semver.org gives for 11.4 in both directions, plus the two rows circlefin#205 lists and the build-metadata cases. All of them fail on main.
|
Expanded to full §11 as suggested. |
|
@JspIIV Thanks for expanding to full SemVer §11 and keeping the Will leave the formal review to maintainers; from the description the §11.4 coverage and the bump look like the right shape relative to #212. |
4 participants
Closes: #205
What
version_gtdropped the pre-release tag from both arguments before comparing anything:So every version sharing a major.minor.patch compared equal, and #205's two cases both came back false:
version_gt 0.3.0 0.3.0-rc.1version_gt 0.3.0-rc.2 0.3.0-rc.1version_gt 1.0.0-beta.11 1.0.0-beta.2version_gt 1.0.0-rc.1 1.0.0version_gt 1.0.0+build.9 1.0.0+build.1The last row is a bonus: on
main, build metadata survives into the numeric compare as a patch of0+build.9and[errors out withinteger expected.Why it matters
Both self-update paths compare the
ARCUP_INSTALLER_VERSIONscraped frommainagainst the local one withversion_gt, andupdate_arcuprefuses to move when it returns false. That line has only ever held0.0.1and0.2.0, so no rc comparison has happened yet — but the accepted format explicitly allows-rc.1, and the first timemaindeclares one, anyone on an earlier rc of that core is stuck.Change
-).prerelease_gtorders two pre-releases identifier by identifier (§11.4): numeric compare as numbers, numeric ranks below alphanumeric, alphanumeric compares byte-wise underLC_ALL=C, shorter list ranks lower when the shared prefix is equal.ARCUP_INSTALLER_VERSION→0.2.1, per the note at the top of the script, so self-update can deliver this.Tests are in
test_arcup.sh: the precedence chain semver.org gives for §11.4, walked in both directions, plus #205's rows and the build-metadata cases. All of them fail onmain.Relation to #212
#212 reached the same conclusion six weeks before this PR and implements the same ordering. It has not been touched since 27 July and does not carry the version bump, which is why this PR was expanded rather than closed in its favour — see the thread. The algorithm here is written from the spec, not from that diff, but the credit for getting there first is #212's.