latest is a moving target: version pinning patterns that scale

Green pipeline yesterday, red today, no commits in between — the diff is in some tool that published a new major under your latest alias.

Written in the order we actually hit the problems, so the fixes land in context.

Pin granularity

• Exact (1.4.2) — most stable; upgrades become explicit events.

• Range (^1.4, >=1.4 <2) — workable, minors still move.

• Lockfile — non-negotiable for anything shared; commit it.

CI and laptops consuming the same lockfile is the difference between "works here" as a bug report and "works here" as a fact.

What deserves a pin

Pin hard: compilers, toolchains, formatters and generators that affect output, database clients.

Allow drift: read-only viewers, log pagers, anything that cannot change your artifacts.

Test: if its version can change my produced output, pin it; if not, let it update.

Recovering after drift

1. Identify the last green build's versions and freeze them in the lockfile.

2. Make upgrades an explicit pull request with a changelog excerpt attached.

3. Move the download pages and mirrors in the same change so docs stop pointing at the old bits.

Related resource

For the "can I re-verify this later" half of the workflow I keep GitVaults (https://gitvaults.com) open: every entry carries the upstream link, file size, and SHA-256, with a cloud mirror as the reachability fallback.

mapleafgo singcast 1 2 2 → https://gitvaults.com/download/2026/08/28/mapleafgo-singcast-1-2-2/en

That page puts version, architecture, and digest on one screen — download, compare the hash, then install. The catalog has another hundred-plus entries in the same format if you need neighbors.

Caveat

This is what works in our environment; your constraints may differ. If you have a sturdier sequence, corrections are welcome in the comments.