Package update cooldown spec - #14983
Conversation
Frulfump
left a comment
Frulfump
left a comment
There was a problem hiding this comment.
Thanks for taking the time to write this up. I added my initial comments but need to think some more about the open questions and future possibilities.
|
|
||
| - **npm** — `min-release-age` in `.npmrc` (in days), added in npm v11.10.0, delays installing newly published versions. | ||
| - **Cargo (Rust)** — [RFC 3923](https://github.com/rust-lang/rfcs/pull/3923) adds `registry.global-min-publish-age` (e.g. `"14 days"`) plus a per-registry `registries.<name>.min-publish-age` override, closely mirroring the per-feed model here. Versions already in `Cargo.lock` are exempt, and an env var can bypass the age for urgent fixes. | ||
| - **Dependabot** — a cooldown option to delay dependency update PRs. |
There was a problem hiding this comment.
Dependabot also supports semver cooldown for some ecosystems which I think is very nice and would like to see the same for this spec/feature. i.e you can choose different cooldowns for major. minor or patch versions (unsure how the 4 part versioning scheme works, with the last one being revision.)
There was a problem hiding this comment.
This feels to me like a "nice to have in a follow up" rather than "must have for the first release". If you disagree, can you help me understand why?
There was a problem hiding this comment.
From a strictly MVP it could be considered nice to have but I worry about that I will run into this need and having to wait a year for it or more for it to be included (on the other hand having to wait longer for the initial feature could also be an issue for me). I guess it could land in a feature band update as well maybe which would be a shorter delay than a year. The risk of it being down-prioritized in the future feels greater than riding on the momentum for the overall feature right now.
One of the reasons for using a cooldown is also for stability purposes (maybe that isn't actually raised as a point in the spec right now, I think it should be) and it's assumed that there's higher risk with major version as they contain breaking changes if the package follows semver (which they don't have too), and assumed higher risk for minor versions as the change is usually larger than a patch update.
For my Dependabot updates of NuGet I use 30 days for major versions, 21 days for minor and 8 days for patch versions. For Dependabot updates of GitHub Actions since that ecosystem doesn't support a semver cooldown I use a cooldown of 30 days, NuGet and Actions aren't really equal since Actions are more likely to be able to access secrets in piplines so I'm more likely to choose a long cooldown either way.
| Feeds that re-publish nuget.org packages are ones that don't intrinsically know that packages came from nuget.org. | ||
| Instead someone, or some other automated process, downloads the package from nuget.org and then pushes the package to the feed. | ||
| In this case, the best case is that the feed lists the publish date as when the package was pushed to the feed. | ||
| But if this is days or weeks after the package was originally published to nuget.org, then from the developer's point of view, NuGet might not behave in the way they expect. |
There was a problem hiding this comment.
"In this case, we recommend feeds apply their own cooldown logic and expose versions that satisfy the organization's requirements. In this case, additional cooldown on the NuGet Client side would be redundant and not needed".
|
|
||
| ### Delayed security fixes | ||
|
|
||
| By using a single cooldown value for all packages in a feed, it means that packages with a known security vulnerability will be delayed just as packages without a known vulnerability. |
There was a problem hiding this comment.
We can more explicitly say that Dependabot will still work for these cases. Also, users will be able to use --force (or similar) in CLI to update to the latest version.
|
|
||
| #### Changes to restore | ||
|
|
||
| Fail restore when cooldown is enabled and at least one `PackageReference` uses a floating version. |
There was a problem hiding this comment.
What if that package reference using a floating version is downloaded from a source that has cooldown not enabled. Do we care about where the package comes from
There was a problem hiding this comment.
What if that package reference using a floating version is downloaded from a source that has cooldown not enabled.
Then restore works as normal.
Do we care about where the package comes from
I don't understand your question. Can you try rephrasing it in another way?
7 participants
Design spec for: #14657