Dependency cooldown policy#4831
Open
sigurdm wants to merge 15 commits into
Open
Conversation
…ons (e.g., only retracted versions)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
The policy only targets hosted dependencies.
Updated the protocol documentation to specify the
publishedproperty 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.
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.pub getReport: Displays available newer versions blocked by the policy next to the resolved packages (e.g., (X available (blocked by cooldown))).