Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
other
Priority:
Normal
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
14 Nov 2015 at 15:48 UTC
Updated:
18 Jun 2025 at 11:01 UTC
Jump to comment: Most recent
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
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.)
Comment #25
quietone commentedComment #26
quietone commentedIn the 10 years this issue the core dev and release process has steadily improved. There is now 1 child issue left and by convention we can close a meta when there is only 1 issue left. I am choosing to do that. If another issue is desired for assisting with the next 10 years of progress, then a new issue can be made. If it references this one it will help any historians wanting to find the details.
I am choosing Fixed because it did provide an overview as the issue summary stated.
Comment #27
quietone commentedI meant to add if some one disagrees then add a comment and make sure to change the issue status to 'Active'.
Comment #29
xjmAgreed with closing; this was about planning the patch minor release cycle for D8. We've long since moved past that to planning major release cycles (with their minor and patch releases) for several subsequent majors.