Last updated 20 April 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

Past milestones

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.
April 5, 2017 8.3.0 released.

Current 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.

Next development cycle TBD #


Overview and major version schedule (#)

Example release cycle timeline (explained below)

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 (#)

Minor version schedule (described below)

  • 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.
release_schedule_caveat.jpg82.3 KB


petershaw9’s picture

The graphic shows security fix support for D8.x LTS extending beyond Y7 whereas text indicates only "until at least 3 months after 10.0.0 is released" which with the example timeframes would be earlier. The graphic should be updated to reflect the position of support as stated.

xjm’s picture

Thanks! As stated above, the diagram is only approximate and the exact timeframes are still under discussion. The diagram will be updated once those discussions are finalized.

matsbla’s picture

Maybe these dates could be provided as an iCalendar so we could subscribe to it an add it to our calendar?

samuel.mortenson’s picture

I'm having some problems understanding how security release windows work between minor version releases.

The "Key dates" table says "September 21, 2016: Final security release window for 8.1.x"

A note later in the docs says "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". 8.2.0 released on October 5th, so that window would close on November 5th.

Am I right in assuming that this means that 8.1.x will not have security fixes committed to it after September 21st, but to protect 8.1.x users any security issues that affect it will be publicly withheld until November 5th?

xjm’s picture

Yes, that is correct. We announced this in for that release, and we will do the same in April for the upcoming release. The only exception would be in case of an already disclosed issue/exploit in the wild/etc.

Any suggestions on what changes we should make to the doc to clarify this?

samuel.mortenson’s picture

I'm glad I was reading the doc right! I think that, because there are so many dates involved here, it might be good to have a statement like:

"When a new minor version is released, the previous minor version becomes immediately unsupported and will no longer receive security updates. Any security issues that affect previous minor versions will be publicly disclosed as early as one month after a new minor release. It is recommended that sites update to new minor versions as soon as possible, to avoid security issues."

I want to make sure users feel pressured to update to newer minor releases. When I've talked to community members and co-workers about Drupal 8, they usually don't know the specifics of minor version security windows. One thing I've heard consistently is that there is some window after a new minor release where a previous minor will still receive security updates, which is obviously not true.

robertoperuzzo’s picture

I've just read this article from osTraining where they say "Drupal 7 is currently the "Long Term Support" version of Drupal.", but in this page (image's note) I read "...the start and end dates for the Drupal 7 LTS are still under discussion.". I'm little bit confused. Could someone tell me if D7 is or not the "official" Drupal LTS version?

This is the answer wrote by the author at the end:

"Update: When I originally wrote this post, it seemed that Drupal's release cycle policies were clear. However, I was wrong, judging by the comments below this post, and on issues such as this one. At the moment, the release cycles for Drupal 7. 8 and 9 seems to be in a state of flux. I'll update this post when firm decisions are made."

Bruno Vincent’s picture

So when will D7 stop getting security updates?

Ball park?

alesr’s picture

When 9.x LTS is released.

Bruno Vincent’s picture

On the graph, what is y1 ? 2016 ? 2017?

xjm’s picture

It's only an illustration of the schedule pattern. The only actual scheduled dates are the ones at the top. The rest is just a sample illustrating what might happen in the future.