The problem
Package publication cooldowns can produce confusing differences between implicit version resolution and explicit package restore.
A publication-age setting sounds like a restore-time block, but package selection, version pinning, and floating references behave differently.
The underlying question is not simply whether the project can perform a task, but how that task can remain understandable, repeatable, and safe as conditions change.
The solution
Use reproducible PowerShell experiments to examine .NET 11 RC2 package availability and restore behavior.
A controlled local feed holds an older 1.0.0 and newer 2.0.0 test package. Five scenarios compare package add, update, explicit restore, and floating restore under a 72-hour cooldown.
Use the findings when deciding whether cooldowns help a dependency-update workflow; complement the setting with other supply-chain controls.
Who it's for
.NET package authors and maintainers investigating restore behavior.
A practical fit is a reader or maintainer who wants a defined workflow and documented boundaries rather than an unexplained one-off operation.
Use the findings when deciding whether cooldowns help a dependency-update workflow; complement the setting with other supply-chain controls.
How it works
Key capabilities and concepts. See the project documentation or source code for implementation details.
Reproducible experiments for .NET 11 RC2 packages
Reproducible experiments for .NET 11 RC2 packages.
A controlled local feed holds an older 1.0.0 and newer 2.0.0 test package. Five scenarios compare package add, update, explicit restore, and floating restore under a 72-hour cooldown.
Compare automatic package version selection against explicit restore
Compare automatic package version selection against explicit restore.
The local experiment isolates the feature and is reproducible, but it does not establish an optimal cooldown duration or prove package safety in real supply chains.
Document observable effects of publication cooldown behavior
Document observable effects of publication cooldown behavior.
Use the findings when deciding whether cooldowns help a dependency-update workflow; complement the setting with other supply-chain controls.
Design decisions that matter
- Compare automatic version selection with explicit restore.
Compare automatic version selection with explicit restore.
The local experiment isolates the feature and is reproducible, but it does not establish an optimal cooldown duration or prove package safety in real supply chains.
- Keep the experiment reproducible.
Keep the experiment reproducible.
A publication-age setting sounds like a restore-time block, but package selection, version pinning, and floating references behave differently.
- Report observations without overstating general conclusions.
Report observations without overstating general conclusions.
A controlled local feed holds an older 1.0.0 and newer 2.0.0 test package. Five scenarios compare package add, update, explicit restore, and floating restore under a 72-hour cooldown.
Explore the implementation
This is a proof of concept; see the repository for scripts, observations, and conclusions.
The local experiment isolates the feature and is reproducible, but it does not establish an optimal cooldown duration or prove package safety in real supply chains.
For exact current usage, prerequisites, and release status, consult the source repository.
Related articles
Engineering context and lessons behind this project.