Drupal 8 has a new upgrade model, and the promise is to make upgrades easy forever. The idea behind the upgrade model is great, and has already been proven in other projects like Symfony. However, there might still be some issues that need to be solved, as demonstrated by the recent 8.3 release and the security release that followed it.
The concept of experimental modules is a key part of the new upgrade model. Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported. As Dries pointed out in his DrupalCon Baltimore Driesnote, experimental modules should not be used in production.
Drupal security releases are provided only for the latest minor release, and older minor releases are considered end-of-life. This is a really strong incentive to upgrade to the latest minor version as soon as possible, as you really want to have security coverage for your production site.
Drupal 8.3.0 was released on 6 April 2017. Drupal 8.3.1 and 8.2.8, containing a critical security fix, had to be released less than two weeks later, on 19 April 2017. The reason for publishing a security release for an end-of-life minor release was that there is a minimum ”grace period” of 1 month between the release of a new minor version and public disclosure of security issues that affect the old minor version. This grace period allows for contrib modules to be updated for the new minor version in case of possible disruptive changes in internal APIs and experimental modules.
Drupal 8.3 added Layout Discovery, a new experimental module that is intended to replace Layout Plugin (9th most popular Drupal 8 contrib module), which is required by Display Suite (22nd) and Panels (31st).
The Display Suite, Panels, Page Manager and Panelizer projects all released new branches compatible with Drupal 8.3 and the experimental Layout Discovery module. The old branches of these modules and the Layout Plugin module itself are NOT compatible with Drupal 8.3. The issue queues of these modules are now full of issues describing upgrade problems resulting in completely broken sites.
So one lesson learned here is that minor upgrades are not always painless to do, at least immediately after a new minor version has been released. In this example case production sites can stick to 8.2.8 and hope all the problems with Layout Discovery and the contrib modules that require it are sorted out soon enough. But 8.2 is officially end-of-life: what happens if a new critical bug is discovered in the meantime?
Even when all the issues related to upgrading to 8.3 and using Layout Discovery are resolved, Layout Discovery is still an experimental module, not recommended for production use. (Admittedly Layout Plugin too is an alpha release, so it or modules requiring it should not be used on a production site. But this is just an example case.)
What should one do to have both a stable and a secure site?
One solution is for contrib modules to offer two versions: one that has experimental modules as dependencies and another that does not. But that is a lot to ask, as even the main branches of so many Drupal 8 modules are still in alpha or beta. Also, in this example case Page Manager depends on Panels which in turn depends on Layout Discovery. With many layers of dependencies even with just one main branch in each module it can sometimes take a lot of time and work just to find out where the root cause of a problem is.
I don’t have a better solution in mind, as I’m not even sure if what I have described here really is a serious problem. If it indeed is a genuine problem I hope it will be resolved sooner rather than later.
Drupal 8 is not doing another thing related to what the Symfony framework and also other frameworks like Zend Framework, CakePHP is doing related to minor version.
Marking EOL to the minor version when the next one comes in is the problem. We need also to set an LTS like this mentioned frameworks do and patch both current and LTS on bug fixes and security issues when are common.
Setting EOL without an LTS puts to much pressure for many people maintaining more websites, as it increases the time needed to make changes to support the upgrades.
Since Drupal 8 came out, I had hoped for the announcement that LTS versions will be in place to allow us to maintain easier projects done. Hope this will be in the future.
I completely agree. I'm almost done with publishing a blog post talking about the same issues and the experience I had with upgrading 8.2 -> 8.3.
I'm a massive fan of DS and Panels, so you can imagine how frustrating the upgrade process was.
I agree *everything* (core / contrib / other) needs to provide *always* a stable + security version. New features can go to an experimental branch although the first one is always available.
I guess in this case the fault is genuinely of DS and Panels not maintaining "stable"(-like) branches for 8.3 too.
There is an issue on Layout Plugin itself about forcing uninstall if the codebase is 8.3, which makes impossible for the developers to provide the gap between D8.3 and DS/Panels stable versions.
Thanks for sharing this.
You're dismissing the fact that Display Plugin itself is not stable yet quite easily. I'd say that is a very significant factor here. If it were stable, this story would have me worried a lot more. In that case, the proper (IMHO) course of action would have been to keep 8.3 compatible with the stable contrib solution as long as the core solution were still experimental. Depending on the level of compatibility between the contributing and core solution, that might or might not require new major versions of the depending modules.
Thanks for your comment, Eelke! Actually I do point out that Layout Plugin is an alpha release, and that maintaining two versions is one solution. This is just an example case of a possible larger problem. Maintaining two versions can mean a lot of extra work for contrib.
Ran into this issues too. What a mess!