Repository navigation
julia: derive stdlib compat entries from the versions bundled across the julia compat range - #16229
Merged
v-robaiken merged 3 commits intoSep 15, 2026
Conversation
IanButterworth
force-pushed
the
julia-stdlib-special-casing
branch
from
September 11, 2026 19:24
50877f3 to
a2e9ca3
Compare
The file parser treated every dependency with a registry entry as updatable, so a stdlib without a compat entry got one synthesized from the registry's latest version: `Artifacts = "1.3.0"` (a bridge package for Julia 1.0-1.5) or `Statistics = "1.11.5"` (an upgradable-stdlib release). Pkg pins a stdlib to the bundled version, so such a bound breaks installation on part of the Julia range the project's own `julia` compat admits. The helper now flags a dependency as a stdlib when Pkg considers it one (current or former) in any Julia release admitted by the `julia` compat entry, sampling one release per distinct stdlib set from the HistoricalStdlibVersions.jl data that Pkg uses for `julia_version` resolution. Flagged dependencies are skipped by the Ruby parser, next to the workspace and `[sources]` skips, so no compat entry is added or updated and no manifest update is proposed. A package that only became a stdlib later (Artifacts before 1.6, StyledStrings before 1.11) is still a regular dependency for a project whose `julia` compat is capped below that release. This matches RegistryCI's AutoMerge guidelines, which exempt stdlibs from the compat requirement. Fixes dependabot#16227 Fixes dependabot#16228 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018B6xwWP9TNVSb5AFmMG6eF
Rather than leaving standard libraries alone entirely, compute the versions a stdlib's compat entry has to admit across the project's `julia` compat range: the bundled version where Pkg pins it (the Julia version itself for stdlibs that were unversioned before 1.11, which is how Pkg resolves them), the newest installable registry release where it is upgradable or not yet a stdlib, and 0.0.0 while the range reaches releases before 1.10, whose `Pkg.test()` sandbox pinned stdlibs to that version. Reduced to the lowest version per caret line this gives `Statistics = "1.10"` for `julia = "1.10"`, `"< 0.0.1, 1"` for `julia = "1"` and `SHA = "0.7, 1"`, as the stdlib compat PSA recommends. The parser passes those versions per project file in the dependency metadata and records no manifest version for stdlibs. The update checker has no registry target for them; the requirements updater adds a missing entry or widens one that fails to admit a needed version, whatever strategy is configured, and never narrows. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018B6xwWP9TNVSb5AFmMG6eF
IanButterworth
force-pushed
the
julia-stdlib-special-casing
branch
from
September 13, 2026 14:08
a2e9ca3 to
174c1ea
Compare
IanButterworth
marked this pull request as ready for review
September 13, 2026 14:08
v-robaiken
approved these changes
Sep 15, 2026
5 tasks done
5 tasks done
IanButterworth
added a commit
to IanButterworth/dependabot-core
that referenced
this pull request
Oct 6, 2026
When the project's `julia` compat entry admits releases before 1.10, Dependabot gives each standard library's compat entry a `<0.0.1` bound, because `Pkg.test()` on those releases gave stdlibs version 0.0.0 (dependabot#16229). Nothing in the PR said so, and users read it as a bug. The file updater now adds one NOTE to the PR, naming each stdlib whose entry gains the bound, saying why, and suggesting raising the `julia` compat entry to 1.10 to drop it. It links the stdlib compat PSA. `Notice.markdown_mode` mapped INFO to `[!INFO]`, which GitHub does not render as an alert. No ecosystem showed an INFO notice in a PR before; it now maps to `[!NOTE]`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v-robaiken
added a commit
that referenced
this pull request
Oct 8, 2026
…16308) When the project's `julia` compat entry admits releases before 1.10, Dependabot gives each standard library's compat entry a `<0.0.1` bound, because `Pkg.test()` on those releases gave stdlibs version 0.0.0 (#16229). Nothing in the PR said so, and users read it as a bug. The file updater now adds one NOTE to the PR, naming each stdlib whose entry gains the bound, saying why, and suggesting raising the `julia` compat entry to 1.10 to drop it. It links the stdlib compat PSA. `Notice.markdown_mode` mapped INFO to `[!INFO]`, which GitHub does not render as an alert. No ecosystem showed an INFO notice in a PR before; it now maps to `[!NOTE]`. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Rob Aiken <v-robaiken@github.com>
5 tasks done
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
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.
Claude:
The Julia file parser treated every dependency with a registry entry as updatable, so a standard library without a compat entry got one synthesized from the registry's latest version:
Artifacts = "1.3.0"(a bridge package for Julia 1.0-1.5) orStatistics = "1.11.5"(an upgradable-stdlib release). Pkg pins a stdlib to the version bundled with Julia, so such a bound breaks installation on part of the Julia range the project's ownjuliacompat entry admits.Detecting stdlibs per Julia release
The helper now flags a dependency as a stdlib when Pkg considers it one (current or former, via
Pkg.Types.is_or_was_stdlib) in any Julia release admitted by the project'sjuliacompat entry. The range is split into eras of constant stdlib set using the HistoricalStdlibVersions.jl data that Pkg itself uses forjulia_versionresolution, plus the running Julia for releases newer than that data. A project without ajuliaentry is assumed to support every release. The check is version-aware rather than a name list:Artifactsstays a regular dependency forjulia = "1.0 - 1.5", andStyledStringsforjulia = "1.0 - 1.10".Deriving the compat entry
For a stdlib the registry's latest release is never the target. Instead the helper computes the versions the compat entry has to admit across the range: the bundled version where Pkg pins the stdlib (the Julia version itself for stdlibs that were unversioned before 1.11, which is how Pkg resolves them), the newest installable registry release where it is upgradable or not yet a stdlib, and
0.0.0while the range reaches releases before Julia 1.10, whosePkg.test()sandbox pinned stdlibs to that version. Reduced to the lowest version per caret line, this is the entry the stdlib compat PSA recommends:julia = "1"julia = "1.10"julia = "1.11"< 0.0.1, 11.101.11< 0.0.1, 1.31.101.11< 0.0.1, 0.7, 10.7, 10.7, 1< 0.0.1, 1.41.61.6The parser passes these versions per project file in the dependency metadata and records no manifest version for stdlibs. The update checker has no registry target for them, so no manifest update is ever proposed; the requirements updater adds a missing entry, or widens an existing one that fails to admit a needed version, regardless of the configured update strategy, and never narrows.
RegistryCI's AutoMerge guidelines currently exempt stdlibs from the compat requirement. CompatHelper.jl started treating stdlib registry releases like any other package in 2023 (JuliaRegistries/CompatHelper.jl#457) and has had the same wrong-bound reports since (JuliaRegistries/CompatHelper.jl#534, JuliaRegistries/CompatHelper.jl#499); its stdlib-aware rework (JuliaRegistries/CompatHelper.jl#529) is still open.
The helper manifest was re-resolved with Pkg on Julia 1.13.0 (the version the image is pinned to since #16249) to add the new dependency.
Resolving manifest updates with
Context(julia_version = <manifest's julia_version>)would be a worthwhile follow-up, but would not have fixed these issues on its own since the compat entries are produced on the Ruby side before Pkg runs.Fixes #16227
Fixes #16228