Voting starts in March for the Drupal Association Board election.
Last updated February 16, 2017.
Starting with Drupal 8.0.0, Drupal core releases will move to a new release cycle schedule, and begin using the semantic versioning (semver) numbering system. (For a video overview of semver you can watch this Semantic Versioning video.) This document describes the core release cycle for all versions of Drupal (including Drupal 6 and 7) from November 19, 2015 on.
Key dates (#)
The minor version numbers in this table assume there are no unscheduled minors (see above). If an unscheduled minor is released, the dates will not change, but subsequent minor version numbers will be incremented.
|First Wednesday of every month||Bugfix release window for Drupal 8.2.x and 7.x|
|Third Wednesday of every month||Security release window for Drupal 8.2.x and 7.x|
|November 19, 2015||Drupal 8.0.0 released|
|February 24, 2016||End-of-life for Drupal 6.|
|April 20, 2016||8.1.0 released.|
|October 5, 2016||8.2.0 released.|
Current development cycle #
|Week of January 30, 2017||8.3.0-alpha1 released and 8.4.x-dev opened.|
|Week of February 13, 2017||8.3.0-beta1 released.|
|Week of February 27, 2017||8.3.0-rc1 released. Final patch release window for 8.2.x (criticals only).|
|March 15, 2017||Final security release window for 8.2.x.|
|April 5, 2017||8.3.0 released.|
Next development cycle #
|Week of July 31, 2017||8.4.0-alpha1 released and 8.5.x-dev opened.|
|Week of August 14, 2017||8.4.0-beta1 released.|
|Week of September 4, 2017||8.4.0-rc1 released. Final patch release window for 8.3.x (criticals only).|
|September 20, 2017||Final security release window for 8.3.x.|
|October 4, 2017||8.4.0 released.|
Overview and major version schedule (#)
Note: The approximate dates and total number of minor versions in the diagram is just an example and should not be relied upon. Furthermore, Drupal 7 and 8 will not necessarily receive security support for as long of a period as is indicated in the diagram, and the start and end dates for the Drupal 7 LTS are still under discussion.
- Patch releases (8.0.1, 8.0.2, etc.) will have a monthly release window, which will address bugs to be fixed.
- Scheduled minor releases (8.1.0, 8.2.0) will be released approximately every six months, and will incorporate new features.
- Previous minor releases will become unsupported when a new minor release is published.
- In rare cases when a particularly severe bugfix is too disruptive for a patch release but cannot wait until the next scheduled minor to resolve, we may release an unscheduled minor release that includes that change only. We will announce this broadly in advance of the release window.
- The final minor release in the 8.x series will be a long-term support (LTS) release.
- Drupal 9.0.x will be branched around the same time as the 8.x LTS release or possibly beforehand, depending on the level of pending work in both branches. After Drupal 9.0.0 is released it will use the same patch/minor release cycle that Drupal 8 did.
- The 8.x LTS release will be fully supported (for bug fixes and security fixes) at least until 3 months after the 9.x LTS release comes out. After that, it will be supported for security fixes only, until at least 3 months after 10.0.0 is released. The community has not yet decided if security support can be extended beyond that point, although there is a desire to support it longer (for example, until 3 months after the 10.x LTS release).
Minor version schedule (#)
- Each minor version has development, beta, and release candidate phases.
- The beta phase begins approximately two months before the minor release date. When the beta phase begins, the development branch for the next minor version opens, and subsequent minor-version-only additions and changes are moved to the next development branch instead.
- The release candidate (RC) phase begins approximately one month before the minor release date. The primary purpose of the release candidate phase is to stabilize the minor version for release, and there are strict guidelines on allowed changes during the release candidate phase. This is usually also the date of the final patch release for the previous minor version, so core issues will be moved from that previous version to the upcoming one.
- There will be a minimum of 1 month between the release of a new minor and public disclosure of any security issues that affect the previous minor, in order to ensure all sites have adequate time to upgrade.
- An open feature development phase for each minor version may begin when the branch is opened, or may begin later, depending on critical and major technical debt for the branch.