Skip to content

Dependency cooldown policy#4831

Open
sigurdm wants to merge 15 commits into
dart-lang:masterfrom
sigurdm:cooldown
Open

Dependency cooldown policy#4831
sigurdm wants to merge 15 commits into
dart-lang:masterfrom
sigurdm:cooldown

Conversation

@sigurdm
Copy link
Copy Markdown
Contributor

@sigurdm sigurdm commented May 26, 2026

An attempt at #4791

Projects can declare a policy block in their pubspec.yaml.
At most one policy definitions is allowed across workspace members to prevent conflicting policies.

For now the only policy is a "cooldown" that restricts which dependencies a package is allowed to take.
Language version needs to be at least 3.13 for a policy to be definable.

Configured by:
min-age (Required): The minimum age duration a package version must have (e.g., 7d, 2w).
exclude (Optional): A list of package names that are exempt from the cooldown policy.
stability (Optional): A boolean flag that blocks package versions if a newer version is published within the cooldown window after its release (indicating a rushed bugfix/unstable release).

Why we have "stability" When a library author publishes a release (e.g., 1.0.0) and quickly follows up with another release (e.g., 1.0.1) within a short window, it strongly suggests that the initial release had a critical regression, compilation failure, or major bug. Resolving to 1.0.0 in this window exposes your project to an inherently flawed/unstable release. Enabling stability: true ensures your solver skips intermediate releases that triggered emergency follow-ups, keeping your dependency graph robust., however this is different from the behavior of most ecosystems corresponding feature. So we keep this optional and off-by-default.

Example:

name: myapp
environment:
  sdk: ^3.13.0
policy:
  cooldown:
    min-age: 7d
    exclude:
      - path # this package is allowed to break the cooldown policy
    stability: true

The policy only targets hosted dependencies.

Updated the protocol documentation to specify the published property as optional (but corresponding to what we do on pub.dev).

Third-party package repositories providing a published property in their version listing will be able to interact with this feature. If they don't provide it, all their non-excluded packages will be blocked from being part of the resolution.

The version solve is restricted from selecting hosted packages that violate the cooldown or stability rules.

Attempts to provide a descriptive version solving failure message indicating the specific version, its release age, and the policy's source location.

When version solving fails due to the cooldown policy, pub suggests excluding the blocked package from the cooldown policy in pubspec.yaml.

$ dart pub get
Resolving dependencies...
Because myapp depends on both bar 1.0.0 and foo any, version solving failed:
  myapp depends on bar 1.0.0 which depends on foo >1.0.0.
  version 1.0.1 of foo is too new (released less than 7 days ago)
  Cooldown policy defined at pubspec.yaml:6
You can try one of the following suggestions to make the pubspec resolve:
* Consider excluding "foo" from the cooldown policy in your pubspec.yaml.
* Try upgrading your constraint on bar: dart pub add bar:^2.0.0

pub outdated: Flags and lists versions that are blocked by the cooldown policy with a descriptive warning: Version X is too new for cooldown policy.

Showing outdated packages.
[*] indicates versions that are not the latest available.
Package Name  Current  Upgradable  Resolvable  Latest
foo           1.0.0    1.0.0       1.0.0       1.0.1*
foo
    Version 1.0.1 is too new for cooldown policy.

pub get Report: Displays available newer versions blocked by the policy next to the resolved packages (e.g., (X available (blocked by cooldown))).

+ foo 1.0.0 (1.0.1 available (blocked by cooldown))

@sigurdm sigurdm requested review from jonasfj and szakarias and removed request for jonasfj May 26, 2026 09:15
@sigurdm sigurdm requested a review from jonasfj May 26, 2026 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant