Drupal release cycle

The Drupal release cycle is the published timetable that decides when new versions of Drupal core appear and when old ones lose support. It uses semantic versioning with three kinds of release: a patch every month, a minor about every six months and a major every two years. A site owner uses it to plan updates before support ends.

How the release cycle works in Drupal 11

The Drupal.org release process overview defines the three types. A major release may contain breaking changes that the continuous upgrade path allows. A minor release brings bug fixes, new features and deprecations, in June and December. A patch release holds bug fixes only. Rare off-schedule minors exist for an important fix that is too disruptive for a patch.

Support follows from the type. A minor gets bug and security fixes for six months and security fixes alone for six more. When a new major ships, the previous major gets a long-term support phase with a maintenance minor every six months.

New versions pass through alpha, beta and release candidate stages. For a minor, each stage lasts about two weeks. For a major, the beta stage lasts two months and the release candidate stage one month. Those are targets; the dates move.

Releases happen in windows. Drupal.org lists a bugfix window on the first Wednesday of the month for 11.4.x and a security window, usually on the third Wednesday, for 11.4.x, 11.3.x and 10.6.x. Not every window produces a release. The Drupal Security Team announces the security ones, and security update covers what to do when one lands.

Example

This is the position on 26 October 2026, from the Drupal.org release pages:

A site on 11.3.20 should plan its move to 11.4.x or to 11.5.0 before that December date. The 11.5.0-beta1 notes also announce deprecations, among them the Search, Settings Tray, Shortcut and Toolbar modules. The notes say they have moved to contributed projects and that more modules may be deprecated before Drupal 12. Such lists can change before the final release.

Common mistakes

• Reading supported as fully fixed. In the second half of its year, a minor receives security fixes only. Bugs you hit stay unfixed there.
• Planning around a date as if it were a promise. Drupal 12 beta1 was scheduled for the week of 14 September 2026 and was released on 30 September. Build slack into any plan that depends on a release.
• Putting a beta on a live site. The 12.0.0-beta2 and 11.5.0-beta1 notes both say betas are not for production.
• Treating the major number as the only deadline. The minor you run has its own end date, which can come years before the major version ends.

For marketing and content teams

The cycle gives you a calendar. Ask your developers which minor your site runs, when its security coverage ends, and which month the next update is planned. Put the third Wednesday of each month in the team calendar as a possible security day, and avoid launching a campaign into that window without a standby plan. A major upgrade is a project with a budget, so raise it early, not in the month support ends. This term covers the timing and support windows; the update term covers the steps, and core explains what the versions contain.

Sources

• Drupal.org: Release process overview
• Drupal.org: Drupal core release cycle overview
• Drupal.org: Drupal core release schedule
• Drupal.org: Drupal core releases
• Drupal.org: Drupal core 11.4.11 release notes
• Drupal.org: Drupal core 11.5.0-beta1 release notes
• Drupal.org: Drupal core 12.0.0-beta2 release notes
• SystemRequirementsHooks, Drupal 11.4.10 source