[FEATURE REQUEST]: Support a minimum package age (“cooldown”) for dependency resolution

[gmpassos]

Problem

Today, when running dart pub get or dart pub upgrade, the resolver may select a version that was published seconds ago on pub.dev.

This increases supply-chain risk. Malicious or compromised packages are often discovered within hours or days after publication. Installing versions immediately after release removes that natural detection window.

Several ecosystems already support a minimum release age policy to mitigate this risk.

Examples from other ecosystems

• Renovate

  {
   "minimumReleaseAge": "7 days"
  }

• Dependabot

  updates:
    - package-ecosystem: npm
      cooldown: "7 days"

• npm-check-updates

  ncu --cooldown 7

Some security platforms such as Snyk even apply a default delay (~21 days) before automatically upgrading dependencies.

The idea is simple: avoid installing versions that are too recent.

---

Proposed feature

Allow pub to ignore versions newer than a configurable time window.

Example in pubspec.yaml:

dependency_resolution:
  minimum_release_age: 7d

Meaning:

Only consider package versions published at least 7 days ago.

---

Allow exceptions for trusted packages

Projects often maintain their own internal or trusted packages, which should not be delayed. To support this, allow an exception list.

Example:

dependency_resolution:
  minimum_release_age: 7d
  minimum_release_age_exceptions:
    - my_core_lib
    - internal_utils

Behavior:

• All dependencies respect the cooldown window.
• Packages listed in minimum_release_age_exceptions can resolve to the latest version immediately.

This allows teams to safely update their own packages while still protecting against risks from the broader ecosystem.

---

Example behavior

Available versions:

Package	Version	Publish time
foo	1.3.2	20 days ago
foo	1.3.3	3 days ago
foo	1.3.4	today
my_core_lib	2.1.0	today

With:

dependency_resolution:
  minimum_release_age: 7d
  minimum_release_age_exceptions:
    - my_core_lib

Resolution result:

foo → 1.3.2
my_core_lib → 2.1.0

---

Possible CLI option

This could also be exposed via CLI:

dart pub get --minimum-release-age=7d

---

Benefits

• Reduces exposure to malicious or compromised packages
• Provides a simple supply-chain security control
• Maintains flexibility for trusted or internally maintained packages
• Avoids reliance on external tooling

---

Summary

Adding a minimum package age policy with an exception list would provide a practical security improvement for the Dart ecosystem while preserving fast iteration for trusted packages.

[gmpassos]

FYI: @kevmoo @mit-mit

[FMorschel]

CC @sigurdm

[sigurdm]

I think this could be a nice feature. Just a few thoughts

If we want this on the command line:

dart pub get currently attempts to get the versions already in your pubspec.lock. It should make no changes. Should dart pub get --minimumReleaseAge just block you from resolving if any of them are too old?

We could make an option dart pub upgrade --minimumReleaseAge which indicates the minimum age of any packages in a new resolution.

stability vs. age:

The mechanism will protect you if the package is retracted/removed from the repository, but if you want a policy of stable features then npm/rfcs#646 (comment) has an interesting point.
If package:foo releases 6.6.6 4 days ago, and makes a fix 6.6.7 2 days ago then dart pub upgrade foo --minimumReleaseAge=3 would still give you the buggy 6.6.6.

It seems the rule should be something like:

• Only use versions that both:
  • are at least x days old
  • did not have newer releases published within x days from their own publication.

Such that if foo 3.3.3 was released 10 days ago and 3.4.0 8 days ago, then the strict constraint 'foo: 3.3.3' should not be able to resolve at all with --minimumReleaseAge=3.

@jonasfj WDYT?

[gmpassos]

For me, the main requirements for this feature are:

• Clear rules and easy-to-understand behavior for the end user.
• The default behavior should be simple and cover the broadest set of use cases.
• Advanced usage should be simple and clearly configurable.

Based on the discussion in this thread, my suggestion is:

pubspec.yaml:

dependency_resolution:
  stability_days: 3d
  minimum_release_age: 7d
  minimum_release_age_exceptions:
    - my_core_lib
  stability_days_exceptions:
    - other_core_lib

dependencies:
  my_core_lib: any
  other_core_lib: any
  foo:
    version: ^2.0.0
    ignore_minimum_release_age: true
    ignore_stability_days: true

Parameters

• stability_days: Minimum number of days during which no newer version of a package may appear before that version becomes eligible for dependency resolution. This ensures that a version has remained unchanged for a stability window before being adopted.
• minimum_release_age: Minimum age a published package version must have before it becomes eligible for resolution, after pass the stability_days rule, if defined.
• minimum_release_age_exceptions: List of packages that bypass the global minimum_release_age rule.
• stability_days_exceptions: List of packages that bypass the global stability_days rule.
• ignore_minimum_release_age: Allows a specific direct dependency to bypass the minimum_release_age rule.
• ignore_stability_days: Allows a specific direct dependency to bypass the stability_days rule.

---

pub get

• If any dependency version (direct or transitive) is skipped because it is too recent or not stable, the CLI should show a warning.
• If a direct dependency violates minimum_release_age/stability_days, the command should fail unless it is marked with ignore_minimum_release_age/ignore_stability_days.
• If the dependency graph cannot be resolved while satisfying the cooldown rules, the command should fail with a clear explanation.

---

dart pub upgrade

• Attempts to resolve to the newest versions available while respecting the pubspec rules.
• If the newest version violates minimum_release_age/stability_days, the solver should fall back to the newest allowed version.
• If no valid version satisfies the constraints and cooldown rules, the command should fail with an explanation.

---

dart pub upgrade --tighten

• Should update the dependency versions in pubspec.yaml, respecting the rules already defined in the pubspec.

[sigurdm]

@jonasfj WDYT?

[gmpassos]

FYI:

Recent news shows how supply-chain attacks through package ecosystems are increasing:

https://www.google.com/search?q=aws+npm+supply+chain&tbm=nws

This makes features like a cooldown period for dependency resolution increasingly important. Package registries are now a major supply-chain attack vector, and malicious or compromised packages have already been used to steal tokens and cloud credentials (including AWS keys) from developer machines and CI environments.

Adding a minimum package age policy would provide a simple but effective layer of protection for the Dart ecosystem.

[karlhorky]

@sigurdm in comment 4004690550:

stability vs. age:

The mechanism will protect you if the package is retracted/removed from the repository, but if you want a policy of stable features then npm/rfcs#646 (comment) has an interesting point. If package:foo releases 6.6.6 4 days ago, and makes a fix 6.6.7 2 days ago then dart pub upgrade foo --minimumReleaseAge=3 would still give you the buggy 6.6.6.

It seems the rule should be something like:

• Only use versions that both:

  • are at least x days old
  • did not have newer releases published within x days from their own publication.

Such that if foo 3.3.3 was released 10 days ago and 3.4.0 8 days ago, then the strict constraint 'foo: 3.3.3' should not be able to resolve at all with --minimumReleaseAge=3.

@sigurdm @gmpassos I also originally thought that the "stability" configuration was an interesting approach, but I've come to the opposite position now, and I don't think that a "stability" configuration would be useful to add - I've written about it a bit in the npm RFC:

• [RRFC] Ability to set minimum maturity (in days) of versions to upgrade npm/rfcs#646 (comment)
• [RRFC] Ability to set minimum maturity (in days) of versions to upgrade npm/rfcs#646 (comment)

I think probably best is to just follow the simpler minimumReleaseAge-style config - prior art from the JS ecosystem:

• npm min-release-age
• Yarn npmMinimalAgeGate
• pnpm minimumReleaseAge
• Bun minimumReleaseAge
• Deno --minimum-dependency-age
• Renovate minimumReleaseAge
• Dependabot cooldown
• npm-check-updates --cooldown

[gmpassos]

FYI:

This article reviews how different tools implement the “cooldown” feature, including npm, pnpm, Yarn, Cargo, pip, Bundler, and Go Modules.

Note: Renovate provides a stabilityDays option.

https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html

[karlhorky]

Note: Renovate provides a stabilityDays option.

That was the old Renovate name. The new name is minimumReleaseAge (linked in my list above) and it doesn't match the stability behavior proposed in npm/rfcs#646 - limonte and I tested it:

• [RRFC] Ability to set minimum maturity (in days) of versions to upgrade npm/rfcs#646 (comment)

[sigurdm]

@karlhorky, thanks for the comments. I actually still think the "stability" concept is more sound.

From your linked comment:

I think from the information from the registry, there is no way to know that 6.6.6 would be buggy and that you would not want this version. It could very well be the case that 6.6.6 is totally fine for your project, and 6.6.7 was an unrelated bump or readme change or something like that. This can even happen for projects that try to follow strict semver.

You cannot know if 6.6.7 is a bugfix or not. But you also could not know that about 6.6.6. The whole point (as I see it) of the feature is to allow time for a released version to "show its worth".

If a package releases a stream of new versions with less than n days in between, then that package is probably not the right one to have as a dependency of an institution that chooses the "cooldown" period anyways.

[sigurdm]

Maybe we could provide both options. I think they can have merit in different situations. Just afraid that the difference is so subtly that it causes unnecessary mental overload for the user.

[karlhorky]

If a package releases a stream of new versions with less than n days in between, then that package is probably not the right one to have as a dependency of an institution that chooses the "cooldown" period anyways.

Sometimes you don't get to choose that - it is not predictable over the lifetime of a package. Package maintenance can change quickly, especially in the age of AI - packages which have released only quarterly are now releasing every few days. Sometimes new packages which track certain things like public data can release very fast, but be valuable to projects valuing stability (which actually theoretically should be every project).

The JS ecosystem has almost exclusively chosen the minimumReleaseAge (cooldown) concept - so this should be the main headliner feature, in my opinion. I think you'll probably find similar decisions in other ecosystems.

---

I think the "stability" concept could possibly be an addon to the minimumReleaseAge (cooldown) as a "nice to have" extension, but it should be disabled by default based on heuristics, as Bun decided to do:

• [RRFC] Ability to set minimum maturity (in days) of versions to upgrade npm/rfcs#646 (comment)

Downsides of a "stability" addon:

• It does have a cost in complexity, for both implementation and long term maintenance
• Also, agreed on the confusion point
• It's probably low value

[gmpassos]

Maybe we could provide both options. I think they can have merit in different situations. Just afraid that the difference is so subtly that it causes unnecessary mental overload for the user.

I agree. The “cooldown” feature serves two main purposes:

• Stability: reducing the risk of issues from new releases. Many of us wait a few weeks before updating an OS, for example, to avoid breaking changes or ending up with a bricked device.

• Security: mitigating the risk of introducing compromised or malicious code into the codebase by allowing time for issues to be identified and fixed by the author or community.

Since both goals are important and strongly aligned, I vote for implementing both from the start. That way, we avoid awkward or disruptive configuration changes later on.