fix(version): make `check` train-aware #116

Merged

Claude-Run merged 1 commit from fix/YT-57-train-aware-version-check into main

2026-07-17 11:14:11 +02:00

Claude-Run commented

2026-07-17 11:13:07 +02:00

Member

yt version check resolved "newer" by listing the registry's package versions and returning the highest v<semver>, ignoring BAKED_TRAIN entirely. yt version update resolves the train first and only compares semver on the release train; on the latest train it fetches the moving latest build directly. The two commands therefore answered different questions for a latest-train binary.

The defect that follows: the latest artifact carries whatever version Cargo.toml held at the commit it was built from, so every merge to main after a release republishes latest at an unchanged version number. check compared the running version against the highest release, saw them equal, and reported "up to date" while newer builds existed. The latest train's whole purpose is to track main, and that was precisely what check was structurally incapable of reporting. The inverse also appeared during the post-release race window, where check advertised a release that update on the latest train would not install.

check now resolves the train the way update does and asks the question each train can answer. On the release train the behavior is unchanged: highest published v<semver> against the running version, which is exactly what update --train release installs. On the latest train it stops comparing semver and compares build identity instead, fetching the published latest checksum sidecar (<url>.sha256, already produced by the release flow and consumed by verify_checksum) and comparing it against the hash of the running binary. That needs no new CI artifact and keys on the same bytes update would install. A missing or unparseable sidecar reports that freshness cannot be determined rather than falling back to the semver comparison that is blind to this train.

Output now names the train it evaluated, since a bare version number is ambiguous on the latest train, and the latest-train arm quotes the build commit instead of a version number. resolve_train and the new resolve_base move to the version module so both commands share one definition, and check gains the same --train override update has. The version check / version update long help documents the two trains and that --train release is how to move to tagged releases.

#YT-57

`yt version check` resolved "newer" by listing the registry's package versions and returning the highest `v<semver>`, ignoring `BAKED_TRAIN` entirely. `yt version update` resolves the train first and only compares semver on the release train; on the latest train it fetches the moving `latest` build directly. The two commands therefore answered different questions for a latest-train binary. The defect that follows: the `latest` artifact carries whatever version `Cargo.toml` held at the commit it was built from, so every merge to `main` after a release republishes `latest` at an unchanged version number. `check` compared the running version against the highest release, saw them equal, and reported "up to date" while newer builds existed. The latest train's whole purpose is to track `main`, and that was precisely what `check` was structurally incapable of reporting. The inverse also appeared during the post-release race window, where `check` advertised a release that `update` on the latest train would not install. `check` now resolves the train the way `update` does and asks the question each train can answer. On the release train the behavior is unchanged: highest published `v<semver>` against the running version, which is exactly what `update --train release` installs. On the latest train it stops comparing semver and compares build identity instead, fetching the published `latest` checksum sidecar (`<url>.sha256`, already produced by the release flow and consumed by `verify_checksum`) and comparing it against the hash of the running binary. That needs no new CI artifact and keys on the same bytes `update` would install. A missing or unparseable sidecar reports that freshness cannot be determined rather than falling back to the semver comparison that is blind to this train. Output now names the train it evaluated, since a bare version number is ambiguous on the latest train, and the latest-train arm quotes the build commit instead of a version number. `resolve_train` and the new `resolve_base` move to the version module so both commands share one definition, and `check` gains the same `--train` override `update` has. The `version check` / `version update` long help documents the two trains and that `--train release` is how to move to tagged releases. #YT-57

Claude-Run added 1 commit

2026-07-17 11:13:08 +02:00

fix(version): make check train-aware

Check / fmt + clippy + build + tests (pull_request) Successful in 59s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

d7b7ef361f

The defect that follows: the `latest` artifact carries whatever version `Cargo.toml` held at the commit it was built from, so every merge to `main` after a release republishes `latest` at an unchanged version number. `check` compared the running version against the highest release, saw them equal, and reported "up to date" while newer builds existed. The latest train's whole purpose is to track `main`, and that was precisely what `check` was structurally incapable of reporting. The inverse also appeared during the post-release race window, where `check` advertised a release that `update` on the latest train would not install.

`check` now resolves the train the way `update` does and asks the question each train can answer. On the release train the behavior is unchanged: highest published `v<semver>` against the running version, which is exactly what `update --train release` installs. On the latest train it stops comparing semver and compares build identity instead, fetching the published `latest` checksum sidecar (`<url>.sha256`, already produced by the release flow and consumed by `verify_checksum`) and comparing it against the hash of the running binary. That needs no new CI artifact and keys on the same bytes `update` would install. A missing or unparseable sidecar reports that freshness cannot be determined rather than falling back to the semver comparison that is blind to this train.

Output now names the train it evaluated, since a bare version number is ambiguous on the latest train, and the latest-train arm quotes the build commit instead of a version number. `resolve_train` and the new `resolve_base` move to the version module so both commands share one definition, and `check` gains the same `--train` override `update` has. The `version check` / `version update` long help documents the two trains and that `--train release` is how to move to tagged releases.

#YT-57