The problem

The version comparison logic in tmpo uses naive integer parsing that violates Semantic Versioning precedence rules. Specifically, it treats prerelease versions (e.g., v1.0.0-rc.1) as "newer" than or equal to their stable counterparts (e.g., v1.0.0) because it splits the version string by dots and often interprets the prerelease tag as an additional "part" or ignores it.

As a result, users running a prerelease version (e.g., v1.0.0-beta) are not prompted to update when the stable version (v1.0.0) is released, because the comparator incorrectly determines they are already up-to-date or ahead of the stable release.

Release version

0.4.1 (01-06-2026)

Operating system

Windows 11

Steps to reproduce the behavior

1. Build tmpo with a prerelease version tag: go build -ldflags "-X ...Version=v1.0.0-rc.1".
2. Ensure the latest release on GitHub is v1.0.0 (stable).
3. Run tmpo version.
4. Observe that no "New Update Available" message appears.
   • Expected: The tool should recognize v1.0.0-rc.1 < v1.0.0 and prompt to update.
   • Actual: The tool calculates v1.0.0-rc.1 >= v1.0.0 and suppresses the notification.

Screenshots

No response

Additional context

The CompareVersions function in internal/update/checker.go splits version strings by . and uses fmt.Sscanf to parse integers.

• For 1.0.0-rc.1, it parses 0-rc as 0, resulting in parts [1, 0, 0, 1].
• For 1.0.0, it results in [1, 0, 0].
• The logic sees the extra part 1 in the prerelease and determines it is "greater" than the stable version.

It may be worth replacing the custom integer parsing logic in internal/update/checker.go with a library such as https://golang.org/x/mod/semver to correctly handle prerelease precedence (where 1.0.0-alpha < 1.0.0).

However, having extra dependencies that don't directly help solve the problem this tool is trying to solve may not be the move. Instead, we may want to modify the custom checker to account for the only way this project will ever version, leaving out the need for an all-encompassing version checker.