This project is not covered by Drupal’s security advisory policy.
Upgrade Policy provides a governance layer on top of Composer outdated results for Drupal projects.
While Composer and Upgrade Status can identify outdated dependencies or upgrade readiness issues, they do not provide a structured way to express team decisions such as:
- why a dependency update is intentionally deferred
- when that decision should be revisited
- which environment or Drupal version the exception applies to
- how the same logic should be reflected in both Drupal admin and CI
Upgrade Policy fills that gap.
Key features
- Context-aware rules for Composer packages
- Administrative UI for policy management
- Classification of outdated packages into:
-
- actionable
- ignored by policy
- review required
- Scan history stored in Drupal
- Audit report for incomplete or expired rules
- Drush commands for CLI and CI workflows
- JSON output for automated pipelines
- Functional integration with Upgrade Status workflows
Typical use case
A Drupal project may intentionally stay on a supported branch of a contributed module while still running Drupal 10, even if a newer branch exists for Drupal 11.
Upgrade Policy allows teams to:
- document that decision
- prevent dependency-check noise
- keep the decision visible to administrators
- automatically revisit it when the core context changes
This module is especially useful for teams managing large-scale Drupal applications with upgrade planning, structured governance, and CI/CD processes.
Project information
- Project categories: Administration tools, Developer tools
- Ecosystem: Development, Administration
- Created by sylv on , updated
This project is not covered by the security advisory policy.
Use at your own risk! It may have publicly disclosed vulnerabilities.
