check-compat-bounds: restore full-workspace resolution + bucket rule#79
Merged
check-compat-bounds: restore full-workspace resolution + bucket rule#79
Conversation
Reverts the core-only resolution introduced in #78 in favor of a more targeted rule that addresses the original "too pedantic" complaint without sacrificing honesty about what the workspace can actually reach. The new rule resolves against the full workspace (weakdeps + subdir projects included, same as pre-#78) and compares the *breaking bucket* of the resolved version against the bucket of the max-allowed version. Breaking buckets: - v >= 1.0 -> (major,) - 0.1 <= v < 1 -> (0, minor) - 0 < v < 0.1 -> (0, 0, patch) Within-bucket gaps (e.g. compat "0.6" resolved at 0.6.4 while 0.6.5 exists) are allowed and no longer flag. Those gaps resolve themselves on the next upstream release and don't change what the package claims to support at the API-break level. Cross-bucket claims (e.g. "0.18, 0.19" resolved at 0.18.22 because a weakdep pins DataStructures) still flag — that's the aspirational-claim case the check is meant to catch. Tested locally against ITensorNetworks (flags DataStructures 0.18/0.19 cross-bucket — legitimate), ITensorFormatter (flags test JuliaSyntax 0.4.10/1 cross-bucket — legitimate; no longer flags the within-bucket Runic "1.5.1" vs 1.7.0 gap), and BlockSparseArrays (flags TensorAlgebra 0.7/0.9 cross-bucket — legitimate; no longer flags the within-bucket MAK 0.6.4/0.6.5 gap, which was the original motivation for the overly-pedantic-check complaint). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mtfishman
added a commit
to ITensor/ITensorFormatter.jl
that referenced
this pull request
Apr 23, 2026
`JuliaFormatter 2.3.0` (the latest registered version) pins `JuliaSyntax` to `0.4.10`. That makes `test/Project.toml`'s entry `JuliaSyntax = "0.4.10, 1"` aspirational — the `1` disjunct is never reachable. Under the compat-bounds check's breaking-bucket rule ([ITensorActions#79](ITensor/ITensorActions#79)), this spans two buckets (0.4 and 1) and fails the check. Narrowing to `"0.4.10"` collapses to a single bucket. Widen back whenever JuliaFormatter ships a release with broader JuliaSyntax compat. ### Supersedes - Closes #52 --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mtfishman
added a commit
to ITensor/ITensorNetworks.jl
that referenced
this pull request
Apr 23, 2026
The `EinExprs` weakdep (via `ITensorNetworksEinExprsExt`) pins `DataStructures` to `0.18`. The `0.19` entry in the root compat is never reachable when the extension is loaded, so it is aspirational. Under the compat-bounds check's breaking-bucket rule ([ITensorActions#79](ITensor/ITensorActions#79)), this spans two buckets (0.18 and 0.19) and fails the check. Narrowing to `"0.18"` collapses to a single bucket. Widen back if `EinExprs` loosens its `DataStructures` compat, or remove the entry entirely once `EinExprs` support is dropped. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mtfishman
added a commit
to ITensor/BlockSparseArrays.jl
that referenced
this pull request
Apr 23, 2026
Follow-up to #258. Under the bucket-rule compat check ([ITensorActions#79](ITensor/ITensorActions#79)), within-bucket gaps no longer fail, so root can go back to `"0.6"` instead of the narrow `"0.6.0 - 0.6.4"`. `test/Project.toml` still needs to exclude MatrixAlgebraKit 0.6.5 because of its JLArrays compat break. Switching from `"0.6.0 - 0.6.4"` to `"0.6.0 - 0.6.4, 0.6.6"` lets the resolver auto-pick up 0.6.6 as soon as it's registered, with no further compat bump required here. The trailing `"0.6.6"` uses bare caret semver (`[0.6.6, 0.7.0)`) so it stays in the 0.6 bucket — `">=0.6.6"` would also admit 0.7+. Closes #259. ### Changes - root: `MatrixAlgebraKit = "0.6.0 - 0.6.4"` → `"0.6"` - test: `MatrixAlgebraKit = "0.6.0 - 0.6.4"` → `"0.6.0 - 0.6.4, 0.6.6"` - Patch version bump. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
Before: the compat-bounds check failed whenever a package's compat entry allowed a version that the resolver could not actually install — even if the gap was only at the patch or minor level within the same breaking-version range.
After: the check only fails when the gap crosses a breaking-version boundary (a major bump for
v >= 1.0, a minor bump for0.x). If the resolver lands on a version in the same breaking range as the max-allowed version, the check passes.This targets the case the check is really meant to catch: a package claims support for a breaking version of a dependency that it cannot actually exercise, because something else in the workspace holds it in an earlier range. Smaller within-range gaps close on their own as upstreams release patches and no longer produce failing checks.
This also restores the original full-workspace resolution (including weakdeps and subdir projects), which #78 had narrowed to root deps only. With the bucket-based comparison in place, the narrower scope is no longer needed to keep the check from being noisy, and the wider scope catches aspirational claims involving optional extensions or test-only deps that #78 missed.