Skip to content

fix(version-check, install): use /tags endpoint, pick highest semver#25

Merged
ilucin merged 1 commit intomainfrom
fix/version-check-use-tags-endpoint
Apr 27, 2026
Merged

fix(version-check, install): use /tags endpoint, pick highest semver#25
ilucin merged 1 commit intomainfrom
fix/version-check-use-tags-endpoint

Conversation

@ilucin
Copy link
Copy Markdown
Contributor

@ilucin ilucin commented Apr 27, 2026

Summary

Today's release of `tb-pr-v0.1.1` exposed a quiet failure mode: GitHub's REST `/repos/.../releases` list endpoint is eventually consistent, and a release published 30+ minutes ago can still be missing from it. Both `toolbox-core::version_check` and `scripts/install.sh` use that endpoint, so a freshly-tagged version silently reports as "(latest)" against the previous one, and `install.sh` happily redownloads the older binary.

gh api repos/productiveio/cli-toolbox/releases  →  tb-pr-v0.1.0  ❌ stale
gh api repos/productiveio/cli-toolbox/tags      →  tb-pr-v0.1.1  ✓ fresh
gh release list                                  →  tb-pr-v0.1.1  ✓ fresh
gh release view tb-pr-v0.1.1                     →  ✓ exists, 2 assets

This switches both call sites to the `/tags` endpoint, which reflects the ref the moment it's pushed. GitHub's tag ordering isn't guaranteed to be by version, so we now collect all `-v*` tags and pick the highest semver instead of trusting the first item from a list endpoint.

Bonus cleanup: extracts `parse_semver` to module scope so `is_newer` and the new `pick_highest_version` share parsing.

Test plan

  • Manual: `get_latest_release tb-pr` (extracted from updated `install.sh`) returns `0.1.1`; previous version returned `0.1.0`.
  • Unit: `pick_highest_version` ignores other tools, malformed tags, and ordering — picks the max semver.
  • `cargo fmt --check`, `cargo clippy --workspace -- -D warnings`, `cargo test --workspace` all green.

🤖 Generated with Claude Code

GitHub's REST `/repos/{owner}/{repo}/releases` list endpoint has
eventual-consistency lag — a release published minutes ago can be
missing from it for hours, even though the underlying release object
is reachable directly via `/releases/tags/<tag>` and shows up in `gh
release list` (GraphQL). When this happens both the in-binary
`version_check` and `scripts/install.sh` silently report the previous
version as latest, so freshly-released bug fixes don't roll out.

Switches both to read `/repos/.../tags?per_page=100`. Tag refs reflect
the moment they're pushed — same source the release pipeline tags
from, so they can't disappoint us. GitHub's tag ordering isn't
guaranteed to be by version, so we collect all `<tool>-v*` tags and
pick the highest semver instead of trusting the first item.

Side-effect cleanup: extracts `parse_semver` to module scope so
`is_newer` and the new highest-version picker share parsing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ilucin ilucin marked this pull request as ready for review April 27, 2026 21:03
@ilucin ilucin merged commit 8a1b99e into main Apr 27, 2026
1 check passed
@ilucin ilucin deleted the fix/version-check-use-tags-endpoint branch April 27, 2026 21:04
@ilucin ilucin mentioned this pull request Apr 27, 2026
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant