[Rovey]

A build with a pre-release suffix (0.4.10-rc2, or the hardware-check test build 0.4.10-check112) was never offered the final release of its own number.

Why

version_number packs only the three numbers, so 0.4.10-check112 and 0.4.10 are the same number. This is on purpose: the 0.4.8 release must not count as a downgrade of 0.4.8-rc1. The update check then offered only a higher number (check_for_update, src/app/common_boot.cpp). As a result, someone who runs a test build of 0.4.10 would stay on it when 0.4.10 is released. The rc builds of 0.4.8 had the same gap.

The change

• release_is_newer(release, running) in core/update decides what is offered:
  • a higher version;
  • or the same number, when the running build carries a pre-release suffix and the release does not.
• check_for_update uses it.
• Released builds have no suffix, so nothing changes for them.
• version_number, the downgrade guard of the logon copy and the version check of a downloaded zip are unchanged.

Not changed

A test build still installs itself as the logon copy when a run saves a result there and apply-at-logon is on (update_logon_copy, since 0.3.1). That is intended, and documented on the PR #87 branch. Once this is merged, such a build is offered the final release when it comes out.

Tests

• cmake --workflow --preset ci (Release, /W4 /WX): no warnings.
• core_tests: 11746 assertions, all passed. app_tests: 297, all passed.
• New test case: a higher release, the final of the rc and test build that runs, not the same final, not an rc over another rc, never a lower one, and nothing that is not a version.

Not to be merged before the owner's review.

🤖 Generated with Claude Code