Repository navigation
Don't flag newer CLT releases as outdated - #24314
Conversation
- `CLT.outdated?` only compared clang builds, but Apple's build numbers can go backwards: the 27.2 release candidate ships `2100.3.34.1`, below 27.0's `2100.3.34.2`. - Treat a package release newer than `latest_version` as current and keep the clang check otherwise, so betas of the recommended release are still flagged. Signed-off-by: Patrick Linnane <patrick@linnane.io>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to
|
MacOS::CLT.outdated?only compared clang build numbers, but Apple's builds can go backwards between releases: the Command Line Tools 27.2 package (27.2.0.0.1792148227) ships clang2100.3.34.1, below the2100.3.34.2in 27.0, sobrew doctoron macOS 27 said a newer release was available and recommended downloading 27.0. A package receipt whose release is newer thanMacOS::CLT.latest_versionis now treated as current; otherwise the clang check still runs, so a receipt for the recommended release with an older compiler and installations without a receipt are still reported.brew benchmarkresults.brewcommands to reproduce the bug?brew lgtm(style, typechecking and tests) locally?Codex (GPT-6 Astra) wrote the change and tests, checked that the new examples fail without the change, compared
brew doctoroutput before and after on an affected macOS 27 machine and ranbrew lgtm. Claude Code (Opus 5.5) reviewed it, suggested the older-release example after finding that replacing>with!=still passed every example, checked the final examples against that and other mutations of the guard and confirmed that the patchedMacOS::CLT.outdated?returnsfalseon the same machine.