rust-lang
Tracking Issue for _lockfile-publish-time_
Summary
Original issue: #5221 Implementation: #16265 Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#lockfile-publish-time
Disallow locking to registry packages newer than a specific time
Unresolved Issues
- [ ] How do we compensate for the caveats, with one option being to leave this perma-unstable?
- [ ] Should we offer a convenient way of getting a compatible timestamp?
- [ ] Stabilization of
pubtime(#16270)
Future Extensions
No response
About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
My understanding of the workflow was to test things at a previous point in time which would be a one-time regeneration of Cargo.toml.
Whats your intended workflow for applying it to all cargo commands?
If it applied to other cargo commands, then it could be used for a "cooldown" to only add or update packages older than some amount of time. Although an option to specify the age rather than the time would probably be more useful.
We are discussing minimum age at #15973.
side note: I dislike the name "cooldown" and surprised Dependabot used it
From #16265
This seemed like the shortest path to testing the proposed pubtime index entries (https://github.com/rust-lang/cargo/issues/15491) so we can unblock other work on it like https://github.com/rust-lang/cargo/issues/15973. While this has some big caveats, the design is straightforward. In contrast, https://github.com/rust-lang/cargo/issues/15973 has a lot more design questions (is this a resolver-wide setting or a per-registry setting, what formats are accepted, etc) that could slow down development and testing pubtime.
I would say we shouldn't grow this to completely cover #15973 but focus this on what it is intended for and do the work to unblock implementation of #15973. Note that there are a lot of design questions in #15973 that can be worked out in parallel to these foundational pieces for the implementation.