feat: `-Zmin-publish-age` (RFC 3923) by weihanglo · Pull Request #17012 · rust-lang/cargo

weihanglo · 2026-05-19T14:50:27Z

What does this PR try to resolve?

This implements RFC 3923 min-publish-age (rust-lang/rfcs#3923, #17009).

The policy lives entirely at the resolver layer. A PublishAgePolicy is built before resolution and applied wherever a version filer needs to be applied

Where the filter is applied

Because the policy is enforced in the resolver, every code path that selects a version outside the resolver must apply it explicitly. Full audit:

Site	Kind	Filtered?
resolver (`dep_cache::query`)	selects (resolution)	yes
`cargo add` (`get_latest_dependency`)	selects (writes `Cargo.toml`)	yes
`cargo add` path/git (`select_package`)	non-registry source	no
`cargo add` features (`populate_available_features`)	enumerates features only	no
`cargo install` (`select_dep_pkg`)	selects (install target)	no
`cargo update --breaking` (`upgrade_dependency`)	selects (writes `Cargo.toml`)	no
`cargo update` report (`report_latest`)	displays "available: vX"	no
future-incompat (`get_updates`)	displays "newer versions"	no
`cargo info` (`query_summaries`)	displays	no

How to test and review this PR?

29 tests in tests/testsuite/min_publish_age.rs cover:

feature gate + ignored-config warnings
deny/allow logic and "0" disabling
per-registry config precedence
lockfile and [patch] preservation of too-new versions
cargo install / cargo add / cargo update --breaking selection paths

Open questions

The version 1.99.0 is too new (published 2d ago) message currenly show the time span in always down to minute, and up to day precise. It is annoying that you would get something like 2d 8h 23m long. We might want to round it more for better UX. I personally would leave it for follow-up.
The registry.min-publish-age / registries.min-publish-age precedence rule basically follows how registry.token is handle. For registry.min-publish-age we only check if the default registyr is crates.io for consistency with token, though it is open to change.

rustbot · 2026-05-19T14:50:35Z

r? @epage

rustbot has assigned @epage.
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: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage

weihanglo · 2026-05-19T14:59:25Z

Found something wrong. Wait a sec.

weihanglo · 2026-05-19T14:51:09Z

+                IndexSummary::TooNew(summary, age) => {
+                    let opts = jiff::SpanRound::new()
+                        .largest(jiff::Unit::Day)
+                        .smallest(jiff::Unit::Minute)
+                        .relative(jiff::SpanRelativeTo::days_are_24_hours());


The version 1.99.0 is too new (published 2d ago) message currenly show the time span in always down to minute, and up to day precise. It is annoying that you would get something like 2d 8h 23m long. We might want to round it more for better UX. I personally would leave it for follow-up.

View changes since the review

@clouatre commented in #17012 (review):

The largest=Day, smallest=Minute rounding produces output like published 2d 8h 23m ago. Suggest simplifying to a single unit based on magnitude: >= 2 days rounds to nearest day (published 3 days ago), < 2 days rounds to nearest hour (published 11 hours ago). The sub-day precision is noise at the day scale and the user cannot act on the minutes component.

For context: we currently enforce this in CI with a bash script that diffs Cargo.lock against the base branch and calls the crates.io API to check publish timestamps on net-new crates. This feature would replace that entirely. The error message is the main user-facing surface, so getting the formatting right matters.

Moved it here so it is better to discuss in a thread.

Plan to leave it in a follow-up since the PR is large in size already

since the PR is large in size already

imo this would be much faster to review if it was broken up even further.

Done in ab157fe

weihanglo · 2026-05-19T14:52:06Z

    }
 }

+fn warn_unused_min_publish_age(gctx: &GlobalContext) -> CargoResult<()> {


We warn all unused min-publish-age all at once, regardless of the precedence rule.

View changes since the review

weihanglo · 2026-05-19T15:25:52Z

I didn't do an extensive testing for different age span. If it is needed let me know

View changes since the review

clouatre

The largest=Day, smallest=Minute rounding produces output like published 2d 8h 23m ago. Suggest simplifying to a single unit based on magnitude: >= 2 days rounds to nearest day (published 3 days ago), < 2 days rounds to nearest hour (published 11 hours ago). The sub-day precision is noise at the day scale and the user cannot act on the minutes component.

For context: we currently enforce this in CI with a bash script that diffs Cargo.lock against the base branch and calls the crates.io API to check publish timestamps on net-new crates. This feature would replace that entirely. The error message is the main user-facing surface, so getting the formatting right matters.

View changes since this review

epage

Having to step away; will have to pick it up later

View changes since this review

epage · 2026-06-13T02:41:58Z

+    // `min-publish-age` policy must be applied here too. Per RFC 3923 it uses
+    // `for_install`: `resolver.incompatible-publish-age` does not apply to
+    // `cargo install`, so `allow` cannot disable the check here.
+    let publish_age = PublishAgePolicy::for_install(gctx)?;


I thought cargo install was to be untouched?

I think there was some ambiguity in the last minute edit: rust-lang/rfcs@6dca5a1.

We can remove this install check if we don't want for now, and discuss before stabilization.

My intention when I signed off on the RFC was that cargo install would not change its behavior which would match what we did with MSRV aware resolver. [registry] sets values but not what to do with them. That is defined in the [resolver] table which does not apply to cargo install.

I somehow missed that edit and had been pushing through the RFC process for the exact opposite.

That edit runs counter to the threads at

https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rfcs/pull/3923#discussion_r2841930230

https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rfcs/pull/3923#discussion_r3162275161

Looks like that edit was made in response to https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rfcs/pull/3923#discussion_r3191124681 after I had checked my box.

The version before the edit:

cargo install also skips pubtime-incompatible versions
as the [resolver] table is documented as not applying to cargo install.

My interpretation of "skip" was the same as the edited version.

It feels more nature. The rationale:

min-publish-age is a registry level config. It also seems nature to apply by default

[resolver] is a global resolver behavior control over other the default registry config.

For example, if in the future we have [[registry.denylist]] then it would also apply to cargo install by default, while resolver.allow-denylist = "deny" (what a bad name) would override registry config. That said, we have globally unique pkgid so we probably won't have denylist under registry.

Anyway, I'll remove that part.

Wow, we had been talking past each other a lot there. For example, I think I had edited in a word and thought you were saying that any of the logic in this RFC would be skipped for cargo install.

epage · 2026-06-13T02:42:31Z

+    /// See the [`invocation_time`] field doc for details.
+    ///
+    /// [`invocation_time`]: GlobalContext::invocation_time
+    pub fn invocation_time(&self) -> jiff::Timestamp {


Does gc have a "now" that can also use this?

Let me see if we can split this off.

Looked into this. gc does have its own now from global_cache_tracker::now() While it is currently pretty close to startup time, GC in the future can be run multiple times other than that. Let's keep them separate for now.

epage · 2026-06-13T02:56:05Z

+/// Mocked "now" for deterministic publish-age comparisons.
+const NOW: &str = "2006-08-08T00:00:00Z";
+
+fn setup_packages() {


publish_packages to better clarify intent?

View changes since the review

epage · 2026-06-13T03:32:55Z

+        .env("__CARGO_TEST_INVOCATION_TIME", NOW)
+        .run();
+
+    p.cargo("update -Zunstable-options -Zmin-publish-age --breaking bar")


Personally, I wouldn't consider it worth including --breaking in this

View changes since the review

Fair enough. Whoever using --breaking may not afraid of breaks. Will abandon the change and document it in the big table in the PR description.

imo --breaking is in too broken of a state.

I kept the tests there just in case we won't forget they are related in the future. Snapshot updates are cheap thanks to snapbox :)

I would rather dump the tests personally and just note this in the tracking issue.

If nothing else, what do we name these tests? Currently, they describe the intended behavior but the test bodies won't match that.

Also warn when `-Zmin-publish-age` is absent

Implement the `-Zmin-publish-age` filter at the resolver layer. The resolver filters out versions that are too new, unless pinned by a lock file or a `[patch]` entry.

When resolution fails because every candidate is newer than the configured `min-publish-age`, report "version X is too new (published N ago)" instead of the generic "version X is unavailable".

Since policy is now in resolver layer, any query doesn't use resolver should enforce the policy if needed. `cargo add` is one of these places.

Report `published 3 days ago` / `published 11 hours ago` instead of a multi-unit span like `2d 8h 23m ago`. Sub-day precision is noise.

weihanglo

All review comments are addressed/replied.

cargo install handling is dropped
cargo update --breaking handling is dropped
Updated `"published 13h 5m 20s" message to a single unit.

View changes since this review

epage · 2026-06-13T19:05:09Z

-fn setup_packages() {
+fn publish_packages() {


Fixed this in the wrong commit?

View changes since the review

epage · 2026-06-13T19:19:57Z

+#[cargo_test]
+fn cargo_install_filters_too_new() {


If we are removing cargo install support, then these test names don't reflect expected behavior: that cargo install is unaffected

View changes since the review

epage · 2026-06-13T19:38:42Z

+        let global = parse(gctx.get::<Option<String>>("registry.global-min-publish-age")?);
+        let crates_io = parse(gctx.get::<Option<String>>("registry.min-publish-age")?);


I take it [registry] is one of those tables that we don't load as a struct but per-field? Or is this related to being unstable?

View changes since the review

epage · 2026-06-13T19:47:13Z

+        let parse = |raw: Option<String>| -> Option<Duration> {
+            let raw = raw?;
+            // A configured value of `"0"` disables the threshold.
+            if raw == "0" {
+                return None;
+            }
+            maybe_parse_time_span(&raw)
+        };
+
+        let global = parse(gctx.get::<Option<String>>("registry.global-min-publish-age")?);
+        let crates_io = parse(gctx.get::<Option<String>>("registry.min-publish-age")?);


maybe_parse_time_span returns None on error but here we are treating None as "unset". See also invalid_publish_age_value which shows no errors which I would expect it would.

View changes since the review

epage · 2026-06-13T19:48:47Z

+    /// 1. `registries.<name>.min-publish-age`
+    /// 2. `registry.min-publish-age` (default registry)
+    /// 3. `registry.global-min-publish-age`
+    fn min_age(&self, source_id: SourceId) -> Option<Duration> {
+        let specific = if let Some(name) = source_id.alt_registry_key() {
+            self.per_registry.get(name).copied()
+        } else if source_id.is_crates_io() {
+            self.crates_io
+        } else {
+            None
+        };


Can you do registries.crates-io?

View changes since the review

epage · 2026-06-13T19:51:38Z

+        } else {
+            None
+        };
+        specific.or(self.global)


"0" means "use latest" but is translated to None above and None is treated here as "unset" and falls back to another source

View changes since the review

epage · 2026-06-13T19:52:33Z

+    /// 1. `registries.<name>.min-publish-age`
+    /// 2. `registry.min-publish-age` (default registry)
+    /// 3. `registry.global-min-publish-age`
+    fn min_age(&self, source_id: SourceId) -> Option<Duration> {


nit: As this is a helper for too_new, personally, i would put too_new first

See also https://epage.github.io/dev/rust-style/#m-caller-callee

View changes since the review

epage · 2026-06-13T20:06:47Z

 [UPGRADING] bar ^1 -> ^2
 [ERROR] failed to select a version for the requirement `bar = "^2.1.0"`
-  version 2.1.0 is unavailable
+  version 2.1.0 is too new (published 1d ago)


In the RFC, we suggested

$ cargo update error: failed to select a version for the requirement `some-package = "^1.3"` version 1.3.0 is too new (published 2 days ago, minimum age 14 days) help: to preserve the min-publish-age, downgrade the version requirement to `"1.1"` help: to use `"1.3"` anyways, re-resolve with `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow`

listing the publish age helps to know which value applied

give next steps both to respect min publish age and to override it

View changes since the review

epage · 2026-06-13T20:08:41Z

 use crate::core::Workspace;
 use crate::core::dependency::DepKind;
 use crate::core::registry::PackageRegistry;
+use crate::core::resolver::PublishAgePolicy;


Should the resolver be home to different policies like this? At first, it was surprising to me. Now, I somewhat get it.

View changes since the review

epage · 2026-06-13T20:10:28Z

+                possibilities.retain(|s| publish_age.too_new(s).is_none());
+                if possibilities.is_empty() && has_candidates {
+                    anyhow::bail!(
+                        "all versions of crate `{dependency}` are too new per `min-publish-age`"


Should we provide more context, like we do with the resolver?

View changes since the review

epage · 2026-06-13T20:12:08Z

-required by package `foo v0.0.0 ([ROOT]/foo)`
+[ADDING] bar v1.0.0 to dependencies
+[LOCKING] 1 package to latest compatible version
+[ADDING] bar v1.0.0 (available: v1.1.0)


The RFC called for these to provide more context, like

Adding some-package v1.2.3 (available: v1.3.0, published 2 days ago)

similar to what we do with msrv, to give users context as to why an old version may be used.

View changes since the review

epage · 2026-06-13T20:12:45Z

Finally was able to sit down and go through the commits. Might also be good to go through the final test state after things get updated.

epage · 2026-06-14T01:31:15Z

    /// Creation time of this config, used to output the total build time
    creation_time: Instant,
+    /// Wall-clock time of this cargo invocation.
+    ///
+    /// Currently used as the reference time for `min-publish-age` and `-Zbuild-analysis`.
+    invocation_time: jiff::Timestamp,


How different are creation_time and invocation_time?

View changes since the review

rustbot assigned epage May 19, 2026

weihanglo marked this pull request as draft May 19, 2026 14:58

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 19, 2026

weihanglo force-pushed the min-publish-age branch 2 times, most recently from 2477e6c to bc3e9c0 Compare May 19, 2026 15:24

weihanglo commented May 19, 2026

View reviewed changes

weihanglo mentioned this pull request May 19, 2026

refactor: drop yanked_whitelist from source loading #17014

Merged

weihanglo force-pushed the min-publish-age branch 2 times, most recently from 1ea1f55 to ddba374 Compare May 19, 2026 15:43

clouatre reviewed May 19, 2026

View reviewed changes

weihanglo marked this pull request as ready for review June 12, 2026 17:18

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 12, 2026

epage reviewed Jun 13, 2026

View reviewed changes

Comment thread tests/testsuite/min_publish_age.rs

weihanglo added 8 commits June 13, 2026 08:43

test: -Zmin-publish-age (RFC 3923)

832f0d3

feat(config): resolver.incompatible-publish-age

364f0e0

Also warn when `-Zmin-publish-age` is absent

fix: warn if -Zmin-publish-age is not used

f7c3211

feat(resolver): filter versions newer than min-publish-age

7c9939c

Implement the `-Zmin-publish-age` filter at the resolver layer. The resolver filters out versions that are too new, unless pinned by a lock file or a `[patch]` entry.

feat(resolver): explain too-new version rejections

68813f7

When resolution fails because every candidate is newer than the configured `min-publish-age`, report "version X is too new (published N ago)" instead of the generic "version X is unavailable".

refactor(resolver): inline args for error messages

d921ae6

feat(add): filter versions newer than min-publish-age

65ae411

Since policy is now in resolver layer, any query doesn't use resolver should enforce the policy if needed. `cargo add` is one of these places.

docs: -Zmin-publish-age (RFC 3923)

ec4f3b6

weihanglo force-pushed the min-publish-age branch from a97b933 to ec4f3b6 Compare June 13, 2026 12:43

fix(resolver): round too-new age to a single unit

ab157fe

Report `published 3 days ago` / `published 11 hours ago` instead of a multi-unit span like `2d 8h 23m ago`. Sub-day precision is noise.

weihanglo commented Jun 13, 2026

View reviewed changes

epage reviewed Jun 13, 2026

View reviewed changes

epage reviewed Jun 14, 2026

View reviewed changes

		let global = parse(gctx.get::<Option<String>>("registry.global-min-publish-age")?);
		let crates_io = parse(gctx.get::<Option<String>>("registry.min-publish-age")?);

		#[cargo_test]
		fn cargo_install_filters_too_new() {

Conversation

weihanglo commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

Where the filter is applied

How to test and review this PR?

Open questions

Uh oh!

rustbot commented May 19, 2026

Uh oh!

weihanglo commented May 19, 2026

Uh oh!

weihanglo May 19, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo May 19, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo May 19, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clouatre left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo Jun 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jun 13, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Jun 13, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo commented May 19, 2026 •

edited

Loading

weihanglo May 19, 2026 •

edited by rustbot

Loading

weihanglo May 19, 2026 •

edited by rustbot

Loading

weihanglo May 19, 2026 •

edited by rustbot

Loading

clouatre left a comment •

edited by rustbot

Loading

epage left a comment •

edited by rustbot

Loading

weihanglo Jun 13, 2026 •

edited

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

weihanglo left a comment •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading

epage Jun 13, 2026 •

edited by rustbot

Loading