feat(resolver): Stabilize min-publish-age by epage · Pull Request #17335 · rust-lang/cargo

epage · 2026-08-07T20:04:56Z

What does this PR try to resolve?

To ensure dependencies have had a chance to be scanned, a user can set:

[registry]
global-min-publish-age = "7 days"

To force a critical update through, a user can

$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p foo

That will be preserved within the lockfile.

To ensure users can observe what is going on and address concerns,

Locking messages notify of:
- That min-publish-age is in use and what the age is if there is a single one
- a newer, unpicked version is available and its age
- a version is being used that is incompatible with min-publish-age (either through allow or an unchange dep shown through -v)
Error messages notify of:
- a newer, unpicked version is available and its age
- a compatible version requirement to downgrade to
- how to use CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE

Fixes #17009

How to test and review this PR?

Items from the tracking issue:

deny precedence between this and incompatible-rust-version: we can always adjust this over time
cargo install behavior
- there was some confusion over what was being stabilized due to edits that happened during the FCP that weren't noticed
- resolver is defined as not affecting cargo install which this preserves, just like incompatible-rust-version
cargo update --breaking: this feature is being stabilized first and the other is being considered for removal (fix(update)!: Remove unstable --breaking #17333)

rustbot · 2026-08-07T20:05:02Z

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @epage, @weihanglo
@epage, @weihanglo expanded to epage, weihanglo

weihanglo · 2026-08-07T20:24:13Z

Before diving into other aspects of the stabilization, have we got any feedback for this using in CI / production?

View changes since the review

Not that I know of.

As identified at rust-lang#17335 (comment)

### What does this PR try to resolve? As identified at rust-lang#17335 (comment) ### How to test and review this PR?

# `[registry]` vs `[registries.<name>]` per-key semantics Review notes for [rust-lang#17335] (min-publish-age stabilization), comparing how each config key behaves across the two tables. Verified against PR head `7b009184` with repro tests in `tests/testsuite/registry_table_confusion.rs` and the PR's own `tests/testsuite/min_publish_age.rs`. [rust-lang#17335]: rust-lang#17335 (comment) | Key | `[registry]` | `[registries.crates-io]` | `[registries.<alt>]` | Evidence | |---|---|---|---|---| | `token` | works for crates.io; does **not** follow `registry.default` | **silently ignored** (config and `CARGO_REGISTRIES_CRATES_IO_TOKEN` env) | works | `registries_crates_io_token_ignored_for_crates_io`, `registry_token_does_not_follow_registry_default` | | `credential-provider` | works for crates.io | **silently ignored** | works | `registries_crates_io_credential_provider_ignored` | | `secret-key` / `secret-key-subject` | works for crates.io | silently ignored (same code path as `token`) | works | code: `src/util/auth/mod.rs:212` returns `[registry]` for crates.io before any name lookup | | `min-publish-age` (new) | crates.io only; ignored for alt registries even with `registry.default` pointing at them | **honored; overrides `registry.min-publish-age`** | honored | `registry_alt_ignores_min_publish_age`, `registries_crates_io_overrides_registry_default` | | `global-min-publish-age` (new) | fallback for **all** registries | silently ignored (not a `RegistryConfig` field) | silently ignored | code: `src/context/schema.rs:530` | | `protocol` | silently ignored (not a `GlobalRegistryConfig` field) | honored | parsed but unused (`_protocol`) | code: `SourceId::crates_io_is_sparse` reads `registries.crates-io.protocol` only | | `index` | hard error: "no longer supported" | silently ignored (`SourceId::alt_registry` short-circuits `crates-io`) | required; defines the registry | code: `check_registry_index_not_set`, `src/workspace/source_id.rs:296` | | `default` | selects target registry for `publish`/`login`/`owner`/`yank` when `--registry`/`--index` absent | silently ignored | n/a | code: `src/util/command_prelude.rs:919` | | `global-credential-providers` | fallback providers for **all** registries | silently ignored | silently ignored | code: `src/util/auth/mod.rs:57` | Key asymmetries: * `min-publish-age` is the first key where `[registries.crates-io]` both works and overrides its `[registry]` counterpart; for the auth keys, `[registries.crates-io]` is dead config. * Auth resolves crates.io **by URL first** (`is_crates_io()`, `src/util/auth/mod.rs:212`); min-publish-age resolves **by name first** (`alt_registry_key()`, `src/resolver/version_prefs.rs:279`). A named mirror of crates.io's index gets `[registry]` credentials but `registries.<mirror>.min-publish-age`. * `registries.<name>.global-min-publish-age` and `registry.protocol` are silent no-ops — the same "subtle `s` distinction" concern raised in [rust-lang#12334](rust-lang#12334 (comment)).

weihanglo · 2026-08-12T19:13:43Z

@rfcbot fcp merge T-cargo

This stabilizes rust-lang/rfcs#3923 the min-publish-age. See the PR description for details.

Drifts from the RFC:

registry.min-publish-age is removed. There are confusion between [registry] and [registries.crates-io] tables and to avoid adding more things onto the confusions, we defer the field.
cargo install not respecting min-publish-age. There was a miscommunication in the RFC over what was being stabilized due to edits that happened during the FCP that weren't noticed. [resolver] is defined as not affecting cargo install which this preserves, just like incompatible-rust-version.

rust-rfcbot · 2026-08-12T19:13:47Z

@weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

To ensure dependencies have had a chance to be scanned, a user can set: ```toml [registry] global-min-publish-age = "7 days" ``` To force a critical update through, a user can ```console $ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p foo ``` That will be preserved within the lockfile. To ensure users can observe what is going on and address concerns, - Locking messages notify of: - That min-publish-age is in use and what the age is if there is a single one - a newer, unpicked version is available and its age - a version is being used that is incompatible with min-publish-age (either through `allow` or an unchange dep shown through `-v`) - Error messages notify of: - a newer, unpicked version is available and its age - a compatible version requirement to downgrade to - how to use `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE` Items from the tracking issue: - `deny` precedence between this and `incompatible-rust-version`: we can always adjust this over time - the `registry.min-publish-age` / `registries.*.min-publish-age` precedence rule: mimics credential providers - `cargo install` behavior - there was some confusion over what was being stabilized due to edits that happened during the FCP that weren't noticed - `resolver` is defined as not affecting `cargo install` which this preserves, just like `incompatible-rust-version` - `cargo update --breaking`: this feature is being stabilized first and the other is being considered for removal (rust-lang#17333) Fixes rust-lang#17009

rust-rfcbot · 2026-08-18T14:01:50Z

🔔 This is now entering its final comment period, as per the review above. 🔔

Cargo's min-publish-age stabilization PR (rust-lang/cargo#17335) is in FCP with disposition-merge, so the nightly-only framing was about to go stale. Repositions the prior-art section on the lockfile carve-out, which does not expire when it ships. Also corrects the PR number, given as #17012 in the original brief.

weihanglo

Stabilization change LGTM.

View changes since this review

FeldrinH · 2026-08-20T20:02:08Z

I'm a bit confused. Does min-publish-age affect cargo install or not?

weihanglo · 2026-08-21T13:28:31Z

I'm a bit confused. Does min-publish-age affect cargo install or not?

No. cargo install works as if there were no such min-publish-age feature.

cargo/tests/testsuite/min_publish_age.rs

Lines 746 to 915 in 0792546

    
           #[cargo_test] 
        
           fn cargo_install_ignores_min_publish_age() { 
        
               Package::new("foo", "1.0.0") 
        
                   .file("src/main.rs", "fn main() {}") 
        
                   .pubtime("2006-07-25T00:00:00Z") 
        
                   .publish(); 
        
               Package::new("foo", "1.1.0") 
        
                   .file("src/main.rs", "fn main() {}") 
        
                   .pubtime("2006-08-06T00:00:00Z") 
        
                   .publish(); 
        
               cargo_process("install foo -Zmin-publish-age") 
        
                   .masquerade_as_nightly_cargo(&["min-publish-age"]) 
        
                   .env("__CARGO_TEST_INVOCATION_TIME", NOW) 
        
                   .env("CARGO_REGISTRY_GLOBAL_MIN_PUBLISH_AGE", "7 days") 
        
                   .with_stderr_data(str![[r#" 
        
           [UPDATING] `dummy-registry` index 
        
           [DOWNLOADING] crates ... 
        
           [DOWNLOADED] foo v1.1.0 (registry `dummy-registry`) 
        
           [INSTALLING] foo v1.1.0 
        
           [COMPILING] foo v1.1.0 
        
           [FINISHED] `release` profile [optimized] target(s) in [ELAPSED]s 
        
           [INSTALLING] [ROOT]/home/.cargo/bin/foo[EXE] 
        
           [INSTALLED] package `foo v1.1.0` (executable `foo[EXE]`) 
        
           [WARNING] be sure to add `[ROOT]/home/.cargo/bin` to your PATH to be able to run the installed binaries 
        
           "#]]) 
        
                   .run(); 
        
               assert_has_installed_exe(paths::cargo_home(), "foo"); 
        
           } 
        
           #[cargo_test] 
        
           fn cargo_install_allows_too_new_deps() { 
        
               Package::new("bar", "1.0.0") 
        
                   .pubtime("2006-07-25T00:00:00Z") 
        
                   .publish(); 
        
               Package::new("bar", "1.1.0") 
        
                   .pubtime("2006-08-06T00:00:00Z") 
        
                   .publish(); 
        
               Package::new("foo", "1.0.0") 
        
                   .dep("bar", "1") 
        
                   .file("src/lib.rs", "") 
        
                   .file("src/main.rs", "extern crate bar; fn main() {}") 
        
                   .pubtime("2006-07-25T00:00:00Z") 
        
                   .publish(); 
        
               cargo_process("install foo -Zmin-publish-age") 
        
                   .masquerade_as_nightly_cargo(&["min-publish-age"]) 
        
                   .env("__CARGO_TEST_INVOCATION_TIME", NOW) 
        
                   .env("CARGO_REGISTRY_GLOBAL_MIN_PUBLISH_AGE", "7 days") 
        
                   .with_stderr_data(str![[r#" 
        
           [UPDATING] `dummy-registry` index 
        
           [DOWNLOADING] crates ... 
        
           [DOWNLOADED] foo v1.0.0 (registry `dummy-registry`) 
        
           [INSTALLING] foo v1.0.0 
        
           [LOCKING] 1 package to highest compatible version 
        
           [DOWNLOADING] crates ... 
        
           [DOWNLOADED] bar v1.1.0 (registry `dummy-registry`) 
        
           [COMPILING] bar v1.1.0 
        
           [COMPILING] foo v1.0.0 
        
           [FINISHED] `release` profile [optimized] target(s) in [ELAPSED]s 
        
           [INSTALLING] [ROOT]/home/.cargo/bin/foo[EXE] 
        
           [INSTALLED] package `foo v1.0.0` (executable `foo[EXE]`) 
        
           [WARNING] be sure to add `[ROOT]/home/.cargo/bin` to your PATH to be able to run the installed binaries 
        
           "#]]) 
        
                    .run(); 
        
               assert_has_installed_exe(paths::cargo_home(), "foo"); 
        
           } 
        
           #[cargo_test] 
        
           fn cargo_install_path_allows_too_new_deps() { 
        
               publish_packages(); 
        
               let p = project() 
        
                   .file( 
        
                       "Cargo.toml", 
        
                       r#" 
        
                           [package] 
        
                           name = "foo" 
        
                           edition = "2021" 
        
                           [dependencies] 
        
                           bar = "1" 
        
                       "#, 
        
                   ) 
        
                   .file( 
        
                       ".cargo/config.toml", 
        
                       r#" 
        
                           [registry] 
        
                           global-min-publish-age = "7 days" 
        
                       "#, 
        
                   ) 
        
                   .file("src/main.rs", "extern crate bar; fn main() {}") 
        
                   .build(); 
        
               p.cargo("install --path . -Zmin-publish-age") 
        
                   .masquerade_as_nightly_cargo(&["min-publish-age"]) 
        
                   .env("__CARGO_TEST_INVOCATION_TIME", NOW) 
        
                   .with_stderr_data(str![[r#" 
        
           [INSTALLING] foo v0.0.0 ([ROOT]/foo) 
        
           [UPDATING] `dummy-registry` index 
        
           [LOCKING] 1 package to highest compatible version as of 7 days ago 
        
           [ADDING] bar v1.0.0 (available: v1.1.0, published 2 days ago) 
        
           [DOWNLOADING] crates ... 
        
           [DOWNLOADED] bar v1.0.0 (registry `dummy-registry`) 
        
           [COMPILING] bar v1.0.0 
        
           [COMPILING] foo v0.0.0 ([ROOT]/foo) 
        
           [FINISHED] `release` profile [optimized] target(s) in [ELAPSED]s 
        
           [INSTALLING] [ROOT]/home/.cargo/bin/foo[EXE] 
        
           [INSTALLED] package `foo v0.0.0 ([ROOT]/foo)` (executable `foo[EXE]`) 
        
           [WARNING] be sure to add `[ROOT]/home/.cargo/bin` to your PATH to be able to run the installed binaries 
        
           "#]]) 
        
                   .run(); 
        
               assert_has_installed_exe(paths::cargo_home(), "foo"); 
        
           } 
        
           #[cargo_test] 
        
           fn cargo_install_locked_allows_too_new_dep() { 
        
               publish_packages(); 
        
               Package::new("foo", "1.0.0") 
        
                   .dep("bar", "1") 
        
                   .file("src/lib.rs", "") 
        
                   .file("src/main.rs", "extern crate bar; fn main() {}") 
        
                   .file( 
        
                       "Cargo.lock", 
        
                       r#" 
        
           [[package]] 
        
           name = "bar" 
        
           version = "1.1.0" 
        
           source = "registry+https://github.com/rust-lang/crates.io-index" 
        
           [[package]] 
        
           name = "foo" 
        
           version = "1.0.0" 
        
           dependencies = [ 
        
            "bar 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", 
        
           ] 
        
           "#, 
        
                   ) 
        
                   .pubtime("2006-07-25T00:00:00Z") 
        
                   .publish(); 
        
               cargo_process("install --locked foo -Zmin-publish-age") 
        
                   .masquerade_as_nightly_cargo(&["min-publish-age"]) 
        
                   .env("__CARGO_TEST_INVOCATION_TIME", NOW) 
        
                   .env("CARGO_REGISTRY_GLOBAL_MIN_PUBLISH_AGE", "7 days") 
        
                   .with_stderr_data(str![[r#" 
        
           [UPDATING] `dummy-registry` index 
        
           [DOWNLOADING] crates ... 
        
           [DOWNLOADED] foo v1.0.0 (registry `dummy-registry`) 
        
           [INSTALLING] foo v1.0.0 
        
           [DOWNLOADING] crates ... 
        
           [DOWNLOADED] bar v1.1.0 (registry `dummy-registry`) 
        
           [COMPILING] bar v1.1.0 
        
           [COMPILING] foo v1.0.0 
        
           [FINISHED] `release` profile [optimized] target(s) in [ELAPSED]s 
        
           [INSTALLING] [ROOT]/home/.cargo/bin/foo[EXE] 
        
           [INSTALLED] package `foo v1.0.0` (executable `foo[EXE]`) 
        
           [WARNING] be sure to add `[ROOT]/home/.cargo/bin` to your PATH to be able to run the installed binaries 
        
           "#]]) 
        
                   .run(); 
        
               assert_has_installed_exe(paths::cargo_home(), "foo"); 
        
           }

rust-lang/cargo maintainer weihanglo confirmed the stabilization PR (rust-lang/cargo#17335, open, not yet merged) targets Rust 1.100.0, due late September 2026 -- see the #17009 tracking issue comment. Replaces the open-ended "once Cargo stabilizes" wording with that concrete version + PR + date, in both .cargo/config.toml's TODO and external-tools.json's rust entry notes.

…td legs Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0, because -Zmin-publish-age -- the cargo dependency-resolution soak feature .cargo/config.toml already configures -- is still nightly-only: verified directly against a real 1.98.0 stable binary, which silently ignores the config with a warning, and against the tracking issue (rust-lang/cargo#17009), still open. The stabilization PR (rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September 2026 -- that's the concrete transition-to-stable target, matching socket-wheelhouse's own canonical rust-toolchain.toml. Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from release-packages.yml -- the nightly + rust-src install steps, the -Z build-std=core,std,panic_abort build branches, the tier3 matrix field, and the staging step's per-platform artifact-copy loop. -Z build-std remains unstable regardless of channel, so this removal is independent of which channel the pin above uses. The perry-ui-tvos/visionos/watchos crates stay in the workspace, and the compiler's own auto-rebuild (perry compile --target tvos-simulator, via a floating +nightly the end user must have installed -- see crates/perry/src/commands/compile/{link/build_and_run,optimized_libs/driver}.rs) is untouched and still exercised by test.yml's tvOS-sim doc-tests; only release-packages.yml's build-and-ship leg for these three platforms is gone. Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem} methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's perf_hooks Histogram) -- safe because it's an internal HdrHistogram- bucketed statistic, not a value any spec requires bit-exact evaluation order for. Recorded in external-tools.json's rust entry as a soakBypass-adopted version (published 2026-08-20, adopted 1 day later, removable 2026-08-27). Verified against the real toolchains, not just docs: installed nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed -Zmin-publish-age activates on the former and is silently ignored on the latter, ran cargo check across perry/perry-runtime/perry-stdlib, and ran the perf_histogram test suite (including Node-oracle-comparison tests) -- all clean. Addresses CodeRabbit's review: fixed stale "stable" wording in release-packages.yml comments/step names and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to release-packages.yml specifically. Left two items as documented follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's recorded toolchain provenance (metadata only, not enforced by gc_ratchet.py, needs a real profiling run to regenerate) and test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild feature (must track whatever nightly the end user has installed, not this repo's CI-only pin).

rustbot · 2026-08-21T20:35:35Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

…td legs Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0, because -Zmin-publish-age -- the cargo dependency-resolution soak feature .cargo/config.toml already configures -- is still nightly-only: verified directly against a real 1.98.0 stable binary, which silently ignores the config with a warning, and against the tracking issue (rust-lang/cargo#17009), still open. The stabilization PR (rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September 2026 -- that's the concrete transition-to-stable target, matching socket-wheelhouse's own canonical rust-toolchain.toml. Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from release-packages.yml -- the nightly + rust-src install steps, the -Z build-std=core,std,panic_abort build branches, the tier3 matrix field, and the staging step's per-platform artifact-copy loop. -Z build-std remains unstable regardless of channel, so this removal is independent of which channel the pin above uses. The perry-ui-tvos/visionos/watchos crates stay in the workspace, and the compiler's own auto-rebuild (perry compile --target tvos-simulator, via a floating +nightly the end user must have installed -- see crates/perry/src/commands/compile/{link/build_and_run,optimized_libs/driver}.rs) is untouched and still exercised by test.yml's tvOS-sim doc-tests; only release-packages.yml's build-and-ship leg for these three platforms is gone. Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem} methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's perf_hooks Histogram) -- safe because it's an internal HdrHistogram- bucketed statistic, not a value any spec requires bit-exact evaluation order for. Recorded in external-tools.json's rust entry as a soakBypass-adopted version (published 2026-08-20, adopted 1 day later, removable 2026-08-27). Verified against the real toolchains, not just docs: installed nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed -Zmin-publish-age activates on the former and is silently ignored on the latter, ran cargo check across perry/perry-runtime/perry-stdlib, and ran the perf_histogram test suite (including Node-oracle-comparison tests) -- all clean. Addresses CodeRabbit's review: fixed stale "stable" wording in release-packages.yml comments/step names and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to release-packages.yml specifically. Left two items as documented follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's recorded toolchain provenance (metadata only, not enforced by gc_ratchet.py, needs a real profiling run to regenerate) and test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild feature (must track whatever nightly the end user has installed, not this repo's CI-only pin).

…td legs Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0, because -Zmin-publish-age -- the cargo dependency-resolution soak feature .cargo/config.toml already configures -- is still nightly-only: verified directly against a real 1.98.0 stable binary, which silently ignores the config with a warning, and against the tracking issue (rust-lang/cargo#17009), still open. The stabilization PR (rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September 2026 -- that's the concrete transition-to-stable target, matching socket-wheelhouse's own canonical rust-toolchain.toml. Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from release-packages.yml -- the nightly + rust-src install steps, the -Z build-std=core,std,panic_abort build branches, the tier3 matrix field, and the staging step's per-platform artifact-copy loop. -Z build-std remains unstable regardless of channel, so this removal is independent of which channel the pin above uses. The perry-ui-tvos/visionos/watchos crates stay in the workspace, and the compiler's own auto-rebuild (perry compile --target tvos-simulator, via a floating +nightly the end user must have installed -- see crates/perry/src/commands/compile/link/build_and_run.rs and crates/perry/src/commands/compile/optimized_libs/driver.rs) is untouched and still exercised by test.yml's tvOS-sim doc-tests; only release-packages.yml's build-and-ship leg for these three platforms is gone. Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem} methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's perf_hooks Histogram) -- safe because it's an internal HdrHistogram- bucketed statistic, not a value any spec requires bit-exact evaluation order for. Recorded in external-tools.json's rust entry as a soakBypass-adopted version (published 2026-08-20, adopted 1 day later, removable 2026-08-27). The newer pinned nightly also surfaces two classes of pre-existing issues that were invisible under the previous floating stable, both fixed here: Atomic::fetch_update was renamed to try_update (8 call sites across gc/barrier, gc/poll_arm, gc/layout_tables, gc/roots/stack_maps, arena/block -- a pure rename, verified against the real try_update signature), and an expanded unused-import lint now catches a redundant `use super::super::*;` sitting alongside `use super::*;` in 33 files (6 in perry-codegen's node_core native table, 27 in perry-runtime's node_stream_constructors/object modules) -- deleted each line and confirmed the workspace still builds and 1051 targeted unit tests still pass. Verified against the real toolchains, not just docs: installed nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed -Zmin-publish-age activates on the former and is silently ignored on the latter, ran the exact CI `warnings` job commands (cargo check -p perry --bins, and cargo check --workspace --all-targets minus the host-incompatible UI crates) under the pinned nightly with RUSTFLAGS=-D warnings -- both clean -- and ran the perf_histogram test suite (including Node-oracle-comparison tests) -- all clean. Addresses CodeRabbit's review: fixed stale "stable" wording in release-packages.yml comments/step names (including two more Tier-3 mentions CodeRabbit's follow-up review caught in create-release and publish-assets) and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to release-packages.yml specifically. Left two items as documented follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's recorded toolchain provenance (metadata only, not enforced by gc_ratchet.py, needs a real profiling run to regenerate) and test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild feature (must track whatever nightly the end user has installed, not this repo's CI-only pin).

…td legs (#8550) Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0, because -Zmin-publish-age -- the cargo dependency-resolution soak feature .cargo/config.toml already configures -- is still nightly-only: verified directly against a real 1.98.0 stable binary, which silently ignores the config with a warning, and against the tracking issue (rust-lang/cargo#17009), still open. The stabilization PR (rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September 2026 -- that's the concrete transition-to-stable target, matching socket-wheelhouse's own canonical rust-toolchain.toml. Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from release-packages.yml -- the nightly + rust-src install steps, the -Z build-std=core,std,panic_abort build branches, the tier3 matrix field, and the staging step's per-platform artifact-copy loop. -Z build-std remains unstable regardless of channel, so this removal is independent of which channel the pin above uses. The perry-ui-tvos/visionos/watchos crates stay in the workspace, and the compiler's own auto-rebuild (perry compile --target tvos-simulator, via a floating +nightly the end user must have installed -- see crates/perry/src/commands/compile/link/build_and_run.rs and crates/perry/src/commands/compile/optimized_libs/driver.rs) is untouched and still exercised by test.yml's tvOS-sim doc-tests; only release-packages.yml's build-and-ship leg for these three platforms is gone. Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem} methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's perf_hooks Histogram) -- safe because it's an internal HdrHistogram- bucketed statistic, not a value any spec requires bit-exact evaluation order for. Recorded in external-tools.json's rust entry as a soakBypass-adopted version (published 2026-08-20, adopted 1 day later, removable 2026-08-27). The newer pinned nightly also surfaces two classes of pre-existing issues that were invisible under the previous floating stable, both fixed here: Atomic::fetch_update was renamed to try_update (8 call sites across gc/barrier, gc/poll_arm, gc/layout_tables, gc/roots/stack_maps, arena/block -- a pure rename, verified against the real try_update signature), and an expanded unused-import lint now catches a redundant `use super::super::*;` sitting alongside `use super::*;` in 33 files (6 in perry-codegen's node_core native table, 27 in perry-runtime's node_stream_constructors/object modules) -- deleted each line and confirmed the workspace still builds and 1051 targeted unit tests still pass. Verified against the real toolchains, not just docs: installed nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed -Zmin-publish-age activates on the former and is silently ignored on the latter, ran the exact CI `warnings` job commands (cargo check -p perry --bins, and cargo check --workspace --all-targets minus the host-incompatible UI crates) under the pinned nightly with RUSTFLAGS=-D warnings -- both clean -- and ran the perf_histogram test suite (including Node-oracle-comparison tests) -- all clean. Addresses CodeRabbit's review: fixed stale "stable" wording in release-packages.yml comments/step names (including two more Tier-3 mentions CodeRabbit's follow-up review caught in create-release and publish-assets) and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to release-packages.yml specifically. Left two items as documented follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's recorded toolchain provenance (metadata only, not enforced by gc_ratchet.py, needs a real profiling run to regenerate) and test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild feature (must track whatever nightly the end user has installed, not this repo's CI-only pin).

…td legs Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0, because -Zmin-publish-age -- the cargo dependency-resolution soak feature .cargo/config.toml already configures -- is still nightly-only: verified directly against a real 1.98.0 stable binary, which silently ignores the config with a warning, and against the tracking issue (rust-lang/cargo#17009), still open. The stabilization PR (rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September 2026 -- that's the concrete transition-to-stable target, matching socket-wheelhouse's own canonical rust-toolchain.toml. Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from release-packages.yml -- the nightly + rust-src install steps, the -Z build-std=core,std,panic_abort build branches, the tier3 matrix field, and the staging step's per-platform artifact-copy loop. -Z build-std remains unstable regardless of channel, so this removal is independent of which channel the pin above uses. The perry-ui-tvos/visionos/watchos crates stay in the workspace, and the compiler's own auto-rebuild (perry compile --target tvos-simulator, via a floating +nightly the end user must have installed -- see crates/perry/src/commands/compile/link/build_and_run.rs and crates/perry/src/commands/compile/optimized_libs/driver.rs) is untouched and still exercised by test.yml's tvOS-sim doc-tests; only release-packages.yml's build-and-ship leg for these three platforms is gone. Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem} methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's perf_hooks Histogram) -- safe because it's an internal HdrHistogram- bucketed statistic, not a value any spec requires bit-exact evaluation order for. Recorded in external-tools.json's rust entry as a soakBypass-adopted version (published 2026-08-20, adopted 1 day later, removable 2026-08-27). The newer pinned nightly also surfaces two classes of pre-existing issues that were invisible under the previous floating stable, both fixed here: Atomic::fetch_update was renamed to try_update (8 call sites across gc/barrier, gc/poll_arm, gc/layout_tables, gc/roots/stack_maps, arena/block -- a pure rename, verified against the real try_update signature), and an expanded unused-import lint now catches a redundant `use super::super::*;` sitting alongside `use super::*;` in 33 files (6 in perry-codegen's node_core native table, 27 in perry-runtime's node_stream_constructors/object modules) -- deleted each line and confirmed the workspace still builds and 1051 targeted unit tests still pass. Verified against the real toolchains, not just docs: installed nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed -Zmin-publish-age activates on the former and is silently ignored on the latter, ran the exact CI `warnings` job commands (cargo check -p perry --bins, and cargo check --workspace --all-targets minus the host-incompatible UI crates) under the pinned nightly with RUSTFLAGS=-D warnings -- both clean -- and ran the perf_histogram test suite (including Node-oracle-comparison tests) -- all clean. Addresses CodeRabbit's review: fixed stale "stable" wording in release-packages.yml comments/step names (including two more Tier-3 mentions CodeRabbit's follow-up review caught in create-release and publish-assets) and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to release-packages.yml specifically. Left two items as documented follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's recorded toolchain provenance (metadata only, not enforced by gc_ratchet.py, needs a real profiling run to regenerate) and test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild feature (must track whatever nightly the end user has installed, not this repo's CI-only pin).

rustbot assigned weihanglo Aug 7, 2026

weihanglo reviewed Aug 7, 2026

View reviewed changes

weihanglo reviewed Aug 10, 2026

View reviewed changes

Comment thread doc/book/src/reference/config.md Outdated

weihanglo reviewed Aug 10, 2026

View reviewed changes

Comment thread doc/book/src/reference/config.md

epage mentioned this pull request Aug 10, 2026

docs(ref): Add missing config env variables #17345

Merged

epage force-pushed the min-publish-age branch from acbbbcc to 7b00918 Compare August 10, 2026 19:29