Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This issue will provide a high-level overview and table of contents of policy and infrastructural issues related to core development following the release of 8.0.0, including:
- When and how 8.1.x and subsequent branches are opened for develoment and prepared for release.
- The workflow for backporting changes between minor versions and from Drupal 8 to Drupal 7.
- The process for adding new features to 8.1.x and beyond (policies and implementation details)
- Etc.
Most discussion should not happen in this issue; instead, discuss in each child issue as appropriate. Add this issue as the parent issue for any relevant proposal or policy.
References
- Drupal core release cycle: major, minor, and patch releases
- Allowed changes during the Drupal 8 release cycle
- Drupal 8's APIs defined
- Backport policy
- Always Be Shippable (Dries' blog post) and Dries' DrupalCon Barcelona keynote
- Infrastructure blockers to 8.0.0, etc.: #2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
Original semver policy discussion
Patch releases (e.g. 8.0.1)
Minor versions (e.g. 8.1.x): Schedule, allowed changes, workflow
- #2455081: [policy, no patch] 8.1.x release schedule
- #2116841: [policy] Decide what the Drupal Public API should be and how to manage it
- #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation
- #2623118: [policy, no patch] Update patch backporting workflow to be compatible with semantic versioning
- #2631820: [policy, then infra] Bulk update core issues for relevant minor versions
Backports, Drupal 7
- #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase
- #2598382: [policy] Adopt a 6-month feature release schedule for Drupal 7 (similar to Drupal 8) and use pseudo-semantic versioning
- #2597872: Allow features to be added during the beta phase, especially if they are backportable to the previous version
- #2462101: [policy, no patch] Update backport policy to account for 8.x minor versions and 7.x divergence
- #2623118: [policy, no patch] Update patch backporting workflow to be compatible with semantic versioning
Comments
Comment #2
xjmComment #3
xjmComment #4
xjmComment #5
xjmComment #6
xjmComment #7
andypostMaybe better to focus on needed changes and try build rfc approach so everyone can participate
I mean a kind of support each feature will require and who's willing to maintain that
That should bring at least a measure of technical debt and help early inform about changes
Comment #8
xjmComment #9
xjmComment #10
xjmComment #16
xjm(One of the D9 issues was under the wrong heading.)