By Nathaniel Catchpole
When Drupal 9 is released, it will be the first major release since semantic versions and six-month minor release cycles were adopted.
Exactly when Drupal 9 might be released has only been a guess so far, and while it's probably still some way off, the sooner we talk about it in the most constructive way, the better prepared everyone will be for when it happens.
Why talk about Drupal 9? Aren't we adding features to Drupal 8 every six months?
Drupal 8 is the first major release to rely on significant third-party supported PHP instances. These dependencies, such as Symfony, Twig, and Guzzle, have their own release and support cycles. As time goes on, these third-party services will gradually phase out security support for the versions we currently rely on; we will then be faced with the scenario of a version that we are left to manage, either by providing security coverage ourselves, or by updating to the latest versions from these open source partners. Because Drupal directly exposes the APIs for many of its instances, major updates to these instances may require API changes to Drupal core, and then a new core version needs to be released. For
example, Drupal 8 currently uses Symfony 3. This version will reach end-of-life (EOL) in November 2021, at which point it will no longer receive security patches. Previous versions of Drupal 8 were based on Symfony 2, but the Drupal 8 core was already upgraded to Symfony 3, during a minor release cycle. Despite all the planning, that upgrade caused some backwards compatibility issues. While upgrading to Symfony 4 has not yet been fully discussed, ideally we would not want to have to do it again.
Assuming Drupal 8 remains on Symfony 3, then ideally we would want to release Drupal 9 as early as possible, before the Symfony EOL date which is planned for November 3rd, 2021. For example, if we want to give Drupal 8 site owners a 12 month window to upgrade their sites to Drupal 9, we would ideally want to release Drupal 9 by the second half of 2020. Otherwise, if we are behind, at worst Drupal 8 will need a Symfony 3 maintainer on staff and Symfony 4 security fixes to be manually performed.
This need to stay on supported versions of third-party instances is really the main driver for releasing Drupal 9. The development and support of Drupal 8 by the community is very active, with hundreds of contributions to each minor release, and we also know that Drupal 8 is a very fast-growing, fast-growing, and highly-relevant way to get the most out of the development. There is a lot of preparation that needs to be done to make the transition to Drupal 9 as smooth as possible; getting it right will take as long as it takes.
What will happen at the end of life (EOL) of Drupal 7?
While the migration path is rapidly approaching full stability, upgrading from Drupal 7 to Drupal 8 is not yet fully supported. The earliest we can expect to have an officially stable and supported migration path for migrating Drupal 7 sites to Drupal 8 is in Drupal 8.6.0 in the second half of 2018, with some contributed modules bolstering this afterwards.
It is a fact that Drupal 7 still supports at least 900 thousand websites in the world. Even if another 200 or 300,000 sites migrate to Drupal 8 by 2020, we will still have more than 500,000 sites that are developed in Drupal 7.
The Drupal core has adopted a continuous and stable update path that allows module maintainers to update gradually your code without backwards compatibility surprises. Due to this practice, we can allow modules to be compatible with both Drupal 8 and, of course, with Drupal 9. It also allows the release of major versions within a scheduled calendar. This differs significantly from previous versions, where module developers could not predict when a new major version would be released and had to deal with developments that ended up being incompatible, even before being born.
While it used to make sense for some developers to 'skip' a major version of Drupal, because of the above, with Drupal 9, it will be very easy to stay on track, and stay in tune with the Drupal core release cycle and versioning. . This means that the path is beginning to be seen for site owners on Drupal 7 to have certainty regarding the question of whether they upgrade to Drupal 8 or wait for Drupal 9, since as soon as they are on Drupal 8 or higher , future updates will not require a rebuild and migration of the site.
Therefore, the need to discuss the Drupal community's support for D7 is on the table, until some point in 2021 or 2022. I think it makes sense to start this discussion now and announce a date this year to give users the maximum amount of time to plan your updates. There was a rumor that core support would end the day the main +2 version came out, but since Drupal 8 to Drupal 9 will be an incremental change, and versions from Drupal 9 onwards will be scriptable, it seems it's time to start the Drupal 7 end-of-life countdown well in advance.
If 2021 or 2022 seems too soon, remember that there are still 60,000 sites on Drupal 6, more than seven years since the release of Drupal 7 and more than two years after the official end of life of Drupal 6. It's also likely that Something similar to Drupal 6's Long Term Support (LTS) program will happen for Drupal 7, regardless of when support is officially withdrawn. The current LTS program requires LTS providers to release all security patches that are publicly released to the community for free, so even after Drupal 7's expiration date, there will still be options for support. and support for security patches.
So what does the timeline look like?
A release timeline may end up looking something like the following, the release numbers are just examples and this is all just to start a conversation on these topics, we are still discussing things like key maintainers and also fundamentals with the security team.
Proposal: Drupal 7 and 8 will be supported one year after 9.0.0.
In short, Drupal 8 and Drupal 7 would be supported for a year after the release of Drupal 9.0.0, after which both Drupal 8 and Drupal 7 are expected to migrate to Drupal 9.
Since it will be much easier to move From Drupal 8 to Drupal 9 than from Drupal 7 to Drupal 9, and we could set the expiration date (EOL) well in advance, it could be that Drupal 7 ends up being supported for longer than Drupal 8. .
Alternative proposal: Drupal 8 support ends one year after 9.0.0, and Drupal 7 support ends two years after 9.0.0.
And Drupal 10?
The Symfony release schedule is, in principle, as follows:
Symfony 5, November 2019
Symfony 6, November 2021
Symfony 7, November 2023
Each major Symfony release is officially supported for a total of five years. Symfony LTS releases have extended support for three years each. (Other Drupal instances might have three-year support cycles, or no time commitment at all.)
Therefore, to benefit from Symfony security support for as long as possible, we would ideally release a major Drupal version within 6-12 months of each major Symfony release, which would give us about four years of officially supported security support from Symfony.
Future releases beyond Drupal 9 might look like the following:
When synchronizing with the Symfony schedule, this would mean a 2-year development cycle for each major release, potentially, with an additional 2-year security support, this without taking into account the PHP cycle and the cycles of other instances of third parties, which could mean that we have four very challenging years ahead of us.
Conclusion
To balance all these conflicting priorities, the main thing to work on is making the transition from Drupal 8 to Drupal 9 as smooth as humanly possible, and this is work that can be scheduled now. Work needs to be done to ensure that Drupal is not left using deprecated code from its open source partners, and that the deprecation of the Drupal core itself is clearly documented and allows properly updated Drupal 8 modules to work unmodified with Drupal 9.0. To
discuss release dates and expiration dates, there are issues for Drupal 7 and Drupal 8 and 9, and more discussion on those issues is the next step in setting dates.
Written by:
Nathaniel Catchpole
A Drupal user since version 4.5, Nathaniel has been a regular contributor to Drupal Core since 2006. He has contributed over 400 patches to Drupal 7, as well as extensive code work. In September 2011, he became a maintainer of a branch of Drupal 8, and has continued as a framework administrator and coordinator of the 8.0.0 release last year. Nathaniel is also co-author of the book “High Performance Drupal”
Thanks to Gábor Hojtsy for preparing the images used in this post.
Translated into Spanish by SeeD EM, Expert Drupal Developers and Consultants in Colombia.
Drupal development.