Change 33502
upgrade.sh, sdp_upgrade.sh: replace naive lexicographic version comparison with a numeric-aware compare_versions() function, fixing false-downgrade detections against non-standard version strings.
Two related, real bugs:
1) sdp_upgrade.sh's SDP-version comparison misclassifies an upgrade as a
downgrade whenever the target version has MORE dot-components than the
source within the same year.N (e.g. old '2026.1' -> new '2026.1.0.BETA'
or '2026.1.0'), since the comparison was plain string '>'/'=='. Confirmed
this would break exactly the transition being planned for a Version-file
format change under discussion (adding a patch component and/or a
pre-release suffix like 'BETA'), even though it doesn't affect real
customers (whose actual prior release, e.g. 2025.2, differs in the year
digit early enough to save the old lexicographic comparison by luck).
2) upgrade.sh has the same class of bug for P4D versions, for years
triggered in practice by Perforce's internal-only P4D builds, which use a
deliberately different version scheme to make it obvious you're not on an
official release (e.g. 'P4D/LINUX26X86_64/2025.1.PREP-TEST_ONLY/2742020')
-- the inserted non-numeric segment broke the same kind of comparison,
plus a second, independent issue: comparing changelist numbers as strings
misorders differing-digit-width values (e.g. '999999' vs '1000000').
Fix: a small compare_versions()/_leading_numeric_version_core() pair
(duplicated identically in both scripts -- they don't share a common
library, and this keeps each self-contained) that separates a trailing
numeric changelist/build number from the 'core' release number, takes only
the LEADING numeric run of the core (silently ignoring any non-numeric
pre-release/internal suffix, which is a cosmetic marker, not an ordering
signal), zero-pads the core to a fixed width, and compares everything
numerically rather than lexicographically. Verified against 12 hand-built
scenarios covering both bugs (normal upgrades, same-version equality
despite differing suffix/CL-embedding shape, internal-build-vs-internal-
build ordering, the digit-width case, and the real 2025.2->2026.1.0 GA
transition) -- all pass. Also verified both scripts' '-man' output is
still complete (581 and 407 lines respectively, unchanged) after the
change, and regenerated doc/gen/{upgrade.sh,sdp_upgrade.sh}.man.txt
accordingly (version-keyword refresh only, no text changes).
Agent: Claude Sonnet 5 (claude-sonnet-5), via Claude Code.
Two related, real bugs:
1) sdp_upgrade.sh's SDP-version comparison misclassifies an upgrade as a
downgrade whenever the target version has MORE dot-components than the
source within the same year.N (e.g. old '2026.1' -> new '2026.1.0.BETA'
or '2026.1.0'), since the comparison was plain string '>'/'=='. Confirmed
this would break exactly the transition being planned for a Version-file
format change under discussion (adding a patch component and/or a
pre-release suffix like 'BETA'), even though it doesn't affect real
customers (whose actual prior release, e.g. 2025.2, differs in the year
digit early enough to save the old lexicographic comparison by luck).
2) upgrade.sh has the same class of bug for P4D versions, for years
triggered in practice by Perforce's internal-only P4D builds, which use a
deliberately different version scheme to make it obvious you're not on an
official release (e.g. 'P4D/LINUX26X86_64/2025.1.PREP-TEST_ONLY/2742020')
-- the inserted non-numeric segment broke the same kind of comparison,
plus a second, independent issue: comparing changelist numbers as strings
misorders differing-digit-width values (e.g. '999999' vs '1000000').
Fix: a small compare_versions()/_leading_numeric_version_core() pair
(duplicated identically in both scripts -- they don't share a common
library, and this keeps each self-contained) that separates a trailing
numeric changelist/build number from the 'core' release number, takes only
the LEADING numeric run of the core (silently ignoring any non-numeric
pre-release/internal suffix, which is a cosmetic marker, not an ordering
signal), zero-pads the core to a fixed width, and compares everything
numerically rather than lexicographically. Verified against 12 hand-built
scenarios covering both bugs (normal upgrades, same-version equality
despite differing suffix/CL-embedding shape, internal-build-vs-internal-
build ordering, the digit-width case, and the real 2025.2->2026.1.0 GA
transition) -- all pass. Also verified both scripts' '-man' output is
still complete (581 and 407 lines respectively, unchanged) after the
change, and regenerated doc/gen/{upgrade.sh,sdp_upgrade.sh}.man.txt
accordingly (version-keyword refresh only, no text changes).
Agent: Claude Sonnet 5 (claude-sonnet-5), via Claude Code.