Skip to content

feat: -Zmin-publish-age (RFC 3923)#17012

Draft
weihanglo wants to merge 11 commits into
rust-lang:masterfrom
weihanglo:min-publish-age
Draft

feat: -Zmin-publish-age (RFC 3923)#17012
weihanglo wants to merge 11 commits into
rust-lang:masterfrom
weihanglo:min-publish-age

Conversation

@weihanglo
Copy link
Copy Markdown
Member

What does this PR try to resolve?

This implements RFC 3923 min-publish-age.

Currently, this works as yanked version
though the logic may diverge when needed.

Some highlights:

  • -Z min-publish-age nightly feature gate
  • IndexSummary::TooNew variant that kind mirrors Yanked semantics
  • Report "version X is too new (published N ago)" in resolution errors

How to test and review this PR?

23 new tests are added covering

  • feature gates and ignoring warnings
  • pubtime-incompat deny/allow logic
  • registry config precedence

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.
  • There are probably other but I forgot. Will update when I have more time during RustWeek.

weihanglo added 3 commits May 19, 2026 12:03
So it can be reused by the upcoming `-Zmin-publish-age`.
Most call sites constructed with an empty allowlist,
and `PackageRegistry::load` was the only place that passed a real list
so we do a post construction after PackageRegistry construction in `load`.
The parameter was only load-bearing for `PackageRegistry`.
@rustbot
Copy link
Copy Markdown
Collaborator

rustbot commented May 19, 2026

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

@rustbot rustbot added A-cli Area: Command-line interface, option parsing, etc. A-configuration Area: cargo config files and env vars A-dependency-resolution Area: dependency resolution and the resolver A-directory-source Area: directory sources (vendoring) A-documenting-cargo-itself Area: Cargo's documentation A-future-incompat Area: future incompatible reporting A-git Area: anything dealing with git A-interacts-with-crates.io Area: interaction with registries A-overrides Area: general issues with overriding dependencies (patch, replace, paths) A-registries Area: registries A-source-replacement Area: [source] replacement A-unstable Area: nightly unstable support A-workspaces Area: workspaces Command-clean Command-install Command-publish Command-vendor S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 19, 2026
@weihanglo weihanglo marked this pull request as draft May 19, 2026 14:58
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 19, 2026
@weihanglo
Copy link
Copy Markdown
Member Author

Found something wrong. Wait a sec.

@weihanglo weihanglo force-pushed the min-publish-age branch 2 times, most recently from 2477e6c to bc3e9c0 Compare May 19, 2026 15:24
Comment on lines +294 to +298
IndexSummary::TooNew(summary, age) => {
let opts = jiff::SpanRound::new()
.largest(jiff::Unit::Day)
.smallest(jiff::Unit::Minute)
.relative(jiff::SpanRelativeTo::days_are_24_hours());
Copy link
Copy Markdown
Member Author

@weihanglo weihanglo May 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

}
}

fn warn_unused_min_publish_age(gctx: &GlobalContext) -> CargoResult<()> {
Copy link
Copy Markdown
Member Author

@weihanglo weihanglo May 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

View changes since the review

Copy link
Copy Markdown
Member Author

@weihanglo weihanglo May 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

View changes since the review

weihanglo added 8 commits May 19, 2026 17:43
So we have a global shaed invocation for `-Zbuild-analysis`
and other upcoming features like `-Zmin-publish-age`.
Also warn when `-Zmin-publish-age` is absent
This implements RFC 3923 min-publish-age.

Currently, this works as yanked version
though the logic may diverge when needed.

Some highlights:

* `-Z min-publish-age` nightly feature gate
* `IndexSummary::TooNew` variant that mirrors `Yanked` semantics
* Report "version X is too new (published N ago)" in resolution errors
Copy link
Copy Markdown

@clouatre clouatre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-cli Area: Command-line interface, option parsing, etc. A-configuration Area: cargo config files and env vars A-dependency-resolution Area: dependency resolution and the resolver A-directory-source Area: directory sources (vendoring) A-documenting-cargo-itself Area: Cargo's documentation A-future-incompat Area: future incompatible reporting A-git Area: anything dealing with git A-interacts-with-crates.io Area: interaction with registries A-overrides Area: general issues with overriding dependencies (patch, replace, paths) A-registries Area: registries A-source-replacement Area: [source] replacement A-unstable Area: nightly unstable support A-workspaces Area: workspaces Command-clean Command-install Command-publish Command-vendor

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants