install.ps1: unpinned resolution throws on rc tags ([version] cast) — mirror install.sh resolve_latest_tag #22
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From the #15/#16 fix pass (fix/15-16-rc-installs, merged 2026-09-13): install.ps1 has the same #15-class bug in its UNPINNED path — line ~72 sorts with a [version] cast on the stripped tag which throws on any rc tag, so unpinned PowerShell installs error on the current live release set (mixed stable+rc). The pinned path is unaffected (the #16 fix covered it). Fix: mirror install.sh resolve_latest_tag (sort key major,minor,patch,is-stable,rc-number). Needs a Windows-test pass — the ditc-e2e win11 VM is the natural harness. Also INSTALL.md:53 still documents only the legacy -rcN form (the dotted form is accepted but undocumented).
Assisted-by: deepnet:synthetic/hf:zai-org/GLM-5.3-Flash (agent-filed)
Failure evidence (captured on win11-test, 2026-09-13): unpinned
install.ps1 -Tool ditodies at line 72 withCannot convert value "rc.13" to type "System.Version"whenever a dito-v4.1.12-rc.N tag exists. Independently reproduced under pwsh 7.4 (container): the sameSort-Object { [version](...) }cast throws the same error on the live tag set — the greedy^.+-v?strip leavesrc.13for the cast on any rc tag.Fix (fix/822-ps1-rc-sort,
25a87d9): ports install.sh's resolve_latest_tag ordering (major, minor, patch, is-stable, rc-number) into install.ps1 asResolve-LatestTag— no[version]cast; each tag parses into a fixed-width zero-padded tuple string compared ordinally. The pinned-Versionpath is untouched (it already verified rc.13 in e2e).One correction to the expected-behavior note ("resolves latest stable v4.1.11"): under the ported #15 ordering, stable beats only its OWN rcs (v4.1.12 > v4.1.12-rc.N); a higher (major, minor, patch) still wins. On today's live set — dito-v4.1.11 stable + dito-v4.1.12-rc.1..rc.13, no v4.1.12 stable — the unpinned path resolves dito-v4.1.12-rc.13, the same tag install.sh resolves for the same set (pinned by tests/install_version_parsing.sh's live-shaped case). v4.1.11 wins the moment no newer X.Y.Z rc exists, and rc tags never throw again. If stable-only resolution for the newer-wave case is wanted, that is an ordering change both installers would need together.
Coverage: tests/install-version-parsing.ps1 (resolver extracted verbatim from install.ps1; same case set as the bash suite + the live-set regression) — green under pwsh 7.4, 16/16 checks; tests/install_ps1_parity.sh gates it on pwsh presence and SKIPs with the reason when pwsh is absent; bash tests/install_version_parsing.sh stays green. The INSTALL.md:53 dotted-rc doc gap mentioned in the issue body is out of this fix's scope.
FIXED by
92e8cec(install.ps1 resolver ported from install.sh #15 ordering; parity suite tests/install-version-parsing.ps1 16/16 under pwsh 7.4 + wrapper tests/install_ps1_parity.sh). Re-verified on win11-test 2026-09-13: unpinnedinstall.ps1 -Tool ditocompletes with no exception and resolves v4.1.12-rc.14 — matching install.sh on the same tag set (newer version-line rc outranks an older stable; stable beats only its own rcs). Note: the earlier e2e expectation of v4.1.11 unpinned was wrong per the #15 ordering; corrected on the evidence comment from the fix worker.