preflight: accept the 0.33.x-dynres version family in cuda-dynres-903 - #218
Merged
Conversation
The v0.33.0-dynres tag (at 5171887, the #217 fold of upstream v0.33.0) makes git describe yield 0.33.0-dynres-0-g... The payload did not move (llama.cpp pin stays 9d77fa172, patchset identical), so both version families deliberately share this profile and its measured values; payload_pin remains the provenance anchor. test_verdicts: 50 OK. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Aug 27, 2026
glennneuber
added a commit
that referenced
this pull request
Aug 27, 2026
…pattern The fix in this branch closes the second occurrence of one defect. A guard is worth more than the fix, because the third is otherwise a matter of time. cuda-dynres-903 and mlx-cuda describe ONE host — both keyed on the containerised `-dynres` stamp of the same CUDA machine, chosen between by --platform rather than by version — so their patterns drifting apart is always a bug. Asserted directly. Every other profile is pinned to an exact baseline on purpose, so the second test asserts the widening was NOT swept into them: mlx-metal's own comment reads "tightened at first baseline", and per ADR 0011 a new version there wants a new profile with re-measured expectations rather than a looser regex. Verified by reintroducing the exact #218 state -- widen one, leave the other -- and confirming the failure names both patterns side by side: AssertionError: 2 != 1 : lineage profiles drifted: {'cuda-dynres-903': '^0\.3[23]\....', 'mlx-cuda': '^0\.32\....'} The docstring records why this class is worth a test at all: the failure is silent in the worst way. `--platform mlx-cuda` does not go red on a stale pattern, it fails to RESOLVE A PROFILE, so the gate becomes unreachable rather than failing. And a version pattern is the one field that breaks by standing still -- every other expectation stays correct until something changes; this one goes stale on a bump that touches nothing else about the profile. verdict gate 52/52. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
glennneuber
added a commit
that referenced
this pull request
Aug 27, 2026
fix(preflight): accept 0.33.x-dynres in mlx-cuda, as #218 did for cuda-dynres-903
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The v0.33.0-dynres fork tag (cut at 5171887, the #217 fold of upstream v0.33.0) changes git describe to 0.33.0-dynres-0-g5171887; the profile pattern hardcoded 0.32. The payload is unchanged (payload_pin 9d77fa172 stays the provenance anchor), so both version families share the profile per the note added inline. Verified: new and old version strings match, 0.34.x rejected, test_verdicts 50 OK.
🤖 Generated with Claude Code