[Gabriel Dufresne (GabrielDuf)]

Follow-up to #5434 for the case reported after #5414 was reopened: scoop status -l lists librehardwaremonitor-dotnet10-nightly 37149234619 -> 38756550835, but UniGetUI shows no update.

Root cause. Scoop nightly manifests use GitHub Actions run IDs as version numbers. Both versions are larger than int.MaxValue, and CoreTools.VersionStringToStruct parsed each segment with int.TryParse, which silently leaves 0 when the number overflows. So both versions became 0.0.0.0, and PackageManager.CompareVersions returned 0. Package.NewerVersionIsInstalled() then concluded that a newer or equal version was already installed, and UpgradablePackagesLoader dropped the update. The Scoop table parsing fixed in #5434 is not involved: the row parses correctly and is lost afterwards.

Fix.

• Version segments are now BigInteger, so unbroken digit runs compare correctly at any length.
• Some digit runs are glued together across a non-separator character (+, space, :, (). These keep the old int limit, including overflow to 0. Otherwise build metadata such as 1.0.0+20260101123456 would become a huge patch number that outranks 1.0.1 and hides that update.
• The parser now parses each segment as soon as it reaches a separator, instead of filling parallel lists and parsing them afterwards.

Known trade-off. A long digit-only version (timestamp or build ID) now ranks above any dotted version. If a vendor switches from 20250301123456 to 2.0.0, the new version reads as a downgrade. 8-digit dates already behaved this way. A test pins this behavior so that changing it has to be a deliberate decision.

Verification.

• End to end: I installed an outdated librehardwaremonitor-dotnet10-nightly (38756550835) from the versions bucket, and scoop status -l reported 39124059524 as available. The unfixed build logged Ignoring package librehardwaremonitor-dotnet10-nightly because a newer or equal version than 39124059524 is already installed.; the fixed build kept the update.
• New tests in ToolsTests and PackageTests cover ordering beyond int and beyond 19 digits, the NewerVersionIsInstalled path for the reporter's versions, the int boundary for glued digit runs, and the timestamp trade-off.
• Existing suites: Core.Tools (392) and PackageEngine (1618 + 2488) tests pass, and both dotnet format whitespace and dotnet format style are clean.

---

Closes #5414

[Copilot]

🟡 Changes recommended

Hashing versions with a large fifth segment still narrows to Int32 and throws an overflow exception.

1 open issue

• GetHashCode overflows on large extra version segments · New

What changed in this PR

Fixes missing Scoop build-ID updates by allowing arbitrarily large numeric version segments, addressing a comparison issue separate from #5434’s table-parsing fix.

Changes:

• Uses BigInteger for version segments.
• Preserves legacy overflow behavior for digit runs joined across non-separator characters.
• Adds comparison and update-detection regression tests.

File	Description
src/​UniGetUI.PackageEngine.Tests/​PackageTests.cs	Tests update detection with large versions and build metadata.
src/​UniGetUI.Core.Tools/​Tools.cs	Widens version segments and refactors parsing.
src/​UniGetUI.Core.Tools.Tests/​ToolsTests.cs	Tests large segments, joined digits, and timestamp ordering.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The focused fix has regression coverage, and no unresolved blocking issues remain.

No open issues 🎉

1 resolved since last review

• GetHashCode overflows on large extra version segments

_{Review effort: Balanced}

[randy-but-a-ro]

🤖 Pull request was approved automatically: the AI review is complete and all its review threads are resolved. 🎉

Integration Details

{
	"deliveryId": "ffc01770-cbee-11f1-833f-29691ec5993a",
	"headSha": "86a6abbe5a883a72def9af01e40a593faee52b49",
	"reviewer": "copilot-pull-request-reviewer[bot]"
}