Yesterday, your CTO mandated that all new CMS builds would be on Drupal and that all existing CMS platforms would be consolidated to Drupal within the next three years. Great! Time to start prioritizing sites, hiring teams, and planning development and launch schedules.
The old methods of release planning don't work anymore
Most enterprise IT organizations are used to a "development" cycle followed by a "maintenance" cycle, at which point you start over again and rebuild with a new development cycle. This type of planning (which Dave Hansen-Lange called the "boom-bust cycle") led to poor user experiences with Drupal 7 sites as they became stale with time, and this type of cycle is impossible to use for a Modern Drupal site.
Drupal now has a different release cycle compared to previous Drupal releases. For example, Drupal 7 was released in January 2011, and ever since has only had bug fixes (with the occasional developer-only feature added). Drupal 5 became unsupported, and Drupal 6 entered its last support phase (until Drupal 8 was released). Product owners of sites big and small found this release process stifling. The web is a very different platform today compared to January 2011—although Drupal 7 is pretty much the same. The slow release cycle also reduced willingness to contribute directly to Drupal. After all, why spend time writing a new feature you can't use until you migrate to the latest major version of Drupal?
Part of why Drupal 8's development took the time it did was to allow for a faster release cycle for features. New features are added in point releases (while code compatibility with prior Drupal releases is broadly maintained). We've seen the benefits of this over the past decade, with new features being added to Drupal with a regular cadence.
Furthermore, security updates are only reliable for the latest minor release. After a minor release, such as Drupal 8.4, security issues in the prior minor release (such as Drupal 8.3) will only be patched for a few weeks, if at all. In other words, to keep your sites secure, you have to be on the latest point release. Minor releases come out about every six months, offering new features and security fixes. Teams need to plan for 1 to 5 developer days of work every six months to keep their sites on the latest minor release and to keep them secure.
Drupal now has a more extended period of overlap of security support when a new major version is released. For example, Drupal 10 was released in December 2022, and Drupal 9 reached EOL in November 2023. This time frame gave site owners about ten months to update their sites to manage deprecated APIs and features.
However, Drupal is not the only software that requires more frequent upgrades. Docker, NodeJS, and PHP all have more aggressive support schedules than similar software may have had in the past. Here lies the core of release planning: synchronizing all of these release schedules with your business.
1. Build a schedule of key dates for your business
In the publishing industry, tentpole events such as tournaments, live events, or holiday specials drive production deadlines. In addition to tentpole events, identify conferences, retreats, and other dates your team may not be available. If they overlap with an EOL of software in your stack, you can try to schedule an upgrade ahead of time.
There are two reasons to identify and socialize these early with the rest of the business. First, these are times when you don't want to schedule maintenance or deployments if you can help it. Second, these key dates are times to be prepared and aware of security release windows. For example, Drupal core security releases are usually on the third Wednesday of the month. If this overlaps with a high-traffic event, planning to deploy and test a security patch before the patch is issued will ensure your site is kept secure and that technical teams aren't stressed out during the process.
2. Build a schedule of your stack and its support windows
Too often, organizations mandate a specific tool (like Drupal or Docker) without budgeting time and money for recurring, required upgrades. Maintenance often means "respond to bug reports from our team and handle outages," instead of "incrementally upgrade software to keep it in supported releases."
Before development begins, teams should gather a list of all key software used in their expected production stack. Then, go to each software release page and find out the start and end dates of support for the current and next few releases. Keep in mind that these can change! PHP recently extended security support for an additional year, while Node.js had to shorten the Node 16 lifecycle by seven months. Use this to create a Gantt chart of support windows.
Here's an example for a project with Drupal, PHP, and Node.js.
Sorting a chart like this by end date can sometimes make it easier to visualize potential scheduling conflicts.
For example, if a site uses nodejs 18.x, we can see that it will go to EOL about one month before Drupal 11.1.0 releases. If you know your team will have significant work on the JavaScript side updating apps to work with a later Node.js version, you'll want to reserve enough capacity for the Drupal 11.1.0 release. Or, you may even want to delay upgrading to Drupal 11 until mid-2025 to take advantage of the longer Drupal 10.4.0 window.
This type of chart also gives teams the power to know if a given technology stack is maintainable for their organization. If it's a small team maintaining a large Drupal site, they may not have the time or expertise to keep up with updates elsewhere in the stack. That may mean they have to stick with LTS releases or avoid software without an LTS available.
Initially, Drupal 8 intentionally did not have LTS releases. There were too many unknowns for the Drupal core team to commit to maintaining a version of Drupal that may fall out of sync with other dependencies like PHP or Symfony. Now, the last minor version of a Drupal release gets an extended support window, lasting ten months from release.
3. Keep Secure by Using a Dependency Updater
Our Development and Support teams have both standardized on a process for updating dependencies that focuses on updating early and updating often. When a security release needs to be deployed quickly, we want to ensure we're deploying the minimum amount of code possible. This process gets security updates out quickly—typically, within hours of an update.
We generally use Renovate, having it file pull requests for any upstream updates in Drupal, JavaScript libraries, or Docker containers. Combined with automated tests, we can treat updating dependencies as a normal, daily process.
A tool like this significantly reduces the effort required to make more significant updates. For example, when Drupal 11 is released, we will know that our clients' sites will have the latest versions of modules installed, many of which will already support Drupal 11.
4. Promote the new features you deploy to your colleagues and users
After doing all this work, you should tell your end users and stakeholders about the gains you've made. Show editorial users how blocks now have a revisions UI. Tell your stakeholders how your API servers respond 15% faster to mobile clients. High-five your developers when they can remove a patch they'd been manually applying to the site.
For larger teams, newsletters and blogs are a great way to communicate these improvements. They are especially useful for core development teams who write and maintain software shared throughout an enterprise.
With a solid grasp of how upstream release schedules affect your product, you can reduce the need for unexpected delays and budget requests. If you're interested in exploring this further with your team, we'd be glad to help.