NuGet Product(s) Involved
Visual Studio Package Management UI and .NET CLI
The Elevator Pitch
Inspired by We should all be using dependency cooldowns.
I think this would apply to any place in NuGet that has an update flow, so namely PM UI package update and the update CLI command.
Right now, NuGet update flows look for the latest version available on the package sources. Some package managers such as uv (Python) and pnpm (JavaScript) have a cooldown feature which means "don't update to a package until it is older than X".
pnpm’s minimumReleaseAge. uv also has exclude-newer, although this specifies an absolute cutoff rather than a rolling cooldown.
We should consider this for NuGet as an opt-in or default change in update behavior. We could also consider implementing this in restore as a "strict mode" (don't download a package older than X) but this may be challenging to implement for protocol reasons.
From the blog post above, 7 days seems to be a sweet spot to prevent impact of many of the recent incidents.
Alternatively, or additionally, we could document how to configure various pipeline tools like Dependabot (docs) to work for NuGet.
This feature throws a wrench into two angles of NuGet restore (above was talking about update flows):
- For floating versions, like
1.*, it would be harder for us to enforce the cooldown. This is because the floating version spec is applied to the NuGet V3 version list protocol which does not have a publish date. We would need to fetch the version metadata resource to get the associated publish date. Or we'd need to augment the version list resource with dates.
- The V3 feed protocol does not enforce immutability. This means that if a project depends on
1.1.0, this content might actually change over time and it would be up to the client to detect and block this. This is a pre-existing issue but I want to call this out since the cooldown wouldn't apply to the package mutation date, for the reasons mentioned in the previous point. This is not a huge deal for NuGet.org since it DOES enforce immutability.
Additional Context and Details
No response
NuGet Product(s) Involved
Visual Studio Package Management UI and .NET CLI
The Elevator Pitch
Inspired by We should all be using dependency cooldowns.
I think this would apply to any place in NuGet that has an update flow, so namely PM UI package update and the update CLI command.
Right now, NuGet update flows look for the latest version available on the package sources. Some package managers such as uv (Python) and pnpm (JavaScript) have a cooldown feature which means "don't update to a package until it is older than X".
We should consider this for NuGet as an opt-in or default change in update behavior. We could also consider implementing this in restore as a "strict mode" (don't download a package older than X) but this may be challenging to implement for protocol reasons.
From the blog post above, 7 days seems to be a sweet spot to prevent impact of many of the recent incidents.
Alternatively, or additionally, we could document how to configure various pipeline tools like Dependabot (docs) to work for NuGet.
This feature throws a wrench into two angles of NuGet restore (above was talking about update flows):
1.*, it would be harder for us to enforce the cooldown. This is because the floating version spec is applied to the NuGet V3 version list protocol which does not have a publish date. We would need to fetch the version metadata resource to get the associated publish date. Or we'd need to augment the version list resource with dates.1.1.0, this content might actually change over time and it would be up to the client to detect and block this. This is a pre-existing issue but I want to call this out since the cooldown wouldn't apply to the package mutation date, for the reasons mentioned in the previous point. This is not a huge deal for NuGet.org since it DOES enforce immutability.Additional Context and Details
No response