registry-index: Add release `date` to Index Format

[reneleonhardt]

Potential use cases:

• Minimum age for dependencies #15973
• Cargo time machine (generate lock files based on old registry state) #5221

---

Problem

The registry-index JSON Schema contains the version in the vers key, but not the release date.
It would be very helpful not having to request the API only for getting this information bit 😄

Coincidentally that date is the default sorting key for the web UI (notice the Sort by drop down).

Example JSON Lines: https://index.crates.io/2/cc

Please note that yanked is included in every line, even if it is false (default is not visualized in the web UI) for most versions in contrast to the release date.

Proposed Solution

Can the schema be extended by the release date which is visualized in HTML
https://crates.io/crates/cc/versions

For example version 1.2.21 has been released on May 2nd, 2025:

"date": "20250502",

Please note that the release date of the first version is always shown in the web UI:

100 of 168 cc versions since December 16th, 2014

Notes

No response

[epage]

@reneleonhardt could you describe your use case for needing to know the date?

Please note that putting a field in the index comes with costs. It will be filled in for every version of every package (at least from the current time on, maybe backfilled). This increases the size of the Index files, making updating of the index take longer. For this reason, the primary purpose of the Index is not to store general crate metadata but to provide what is needed for dependency resolution without further API calls or downloading a .crate file. #5221 could provide a motivation for doing so for dependency resolution but we likely couldn't fully resolve that request because we don't track the full history of yanking and unyanking to know the exact state of the crate for the given target-time.

[reneleonhardt]

I don't want to persuade you if you don't have the resources for a new attribute 😄
I just saw that 99% of all lines were filled with a default yanked: false but the unique date information is missing.

My use case would be to parse Cargo.lock files and combine it with all available releases to display possible updates.

cargo update --verbose is not very intuitive.
The first call only updates Cargo.lock while displaying no available versions at all.
The second call only shows available versions of the form

Unchanged core-foundation v0.9.4 (available: v0.10.0)

And cargo update doesn't allow bumping Cargo.toml, so most of the time developers don't even know when a new minor update of a dependency has been released.

My tool shows for a typical go.mod for example:

Module	Required	Update	Old	New	Debt	Type
github.com/go-openapi/jsonreference	v0.20.2	v0.20.5	2023-01-14	2024-03-04	415 days	patch
github.com/go-openapi/jsonreference	v0.20.2	v0.21.0	2023-01-14	2024-03-09	420 days	minor
...	...	...	...	...	...	...
Technical Debt (29 years)	Patch	6245 days (17 years)	Minor	5022 days (14 years)	Total	10417 days (29 years)

[epage]

I just saw that 99% of all lines were filled with a default yanked: false but the unique date information is missing.

Yes, we require the populating of fields that were initially required so the Index can be read by old versions of Cargo. See #14506 for more details.

cargo update --verbose is not very intuitive.

We are open to discussing improvements. The question of what is "intuitive" is dependent on the end-user and their goals though.

The first call only updates Cargo.lock while displaying no available versions at all.

Not quite sure what you are getting at with this.

And cargo update doesn't allow bumping Cargo.toml, so most of the time developers don't even know when a new minor update of a dependency has been released.

Yes, this is being tracked in #12425.

[reneleonhardt]

Just an example that the release date is available in static dumps:
https://crates.io/data-access#rss-feeds
https://static.crates.io/rss/crates/cc.xml

But only the last 10 releases are being published.
And there is no stable feed, so for example you can see the latest 0.8.2 but not 0.8.1 because there were 17 alpha versions between them, but most developers don't rely on prerelease versions:
https://crates.io/crates/schemars/versions

FYI, if yanked is considered to be important (not optional), it's missing in the rss schema (i.e. 0.14.4 has been yanked a year ago).
https://static.crates.io/rss/crates/hashbrown.xml
https://crates.io/crates/hashbrown/versions

[kornelski]

The release date would be useful for gradual rollouts or for delaying updates as a precaution against rapidly-spreading supply-chain attacks: #15973 #11167

OTOH, https://crates.io/api/v1/crates/cc already includes a list of versions with dates (and even a history of yanks), so the complete data can be gathered if necessary. It just wouldn't be as easily usable by cargo due to usage policy/rate limits.

[cuviper]

I've also been thinking about dates to find out which of my dependencies haven't been updated in a long time, as a proxy for "possibly unmaintained". I suppose the static RSS feed might be good enough for that though.

[epage]

@rust-lang/crates-io any input on making published dates available in the Index so cargo can

• avoid resolving to "too new" dependencies (Minimum age for dependencies #15973)
• resolver dependencies to a date (Cargo time machine (generate lock files based on old registry state) #5221)
  • this does have more questions about yanked packages

The main questions I would have for this are

• what do we name the field
• what format do we store the date in

[Turbo87]

any input on making published dates available in the Index

I'm all for it :)

what do we name the field

we use created_at in the database, but I'm not a big fan of that naming. I would suggest using something like pubtime (abbreviation for publish time, since the index format seems to prefer short keys).

what format do we store the date in

ISO8601 with UTC timezone (e.g. 2025-11-12T19:30:12Z)

[epage]

I'm good with all of that.

To move this forward, we'd need support in crates.io and cargo and an FCP for each team before any non-reserseable decisions (e.g. stabilizing it within cargo).

We'll need to make sure we have tests for this. We could likely extend cargo-test-support to allow setting pubtime on .crates.