![]() We only get the changes proven and Drupal 9 battle tested if developers do keep their code updated. While Drupal 9 will be mostly the same as Drupal 8 (no new paradigms of development, etc.), the extent of deprecated code will not be trivial to process all at once. That is exactly what we are trying to avoid. So why not do it the same way contributed module and theme developers always did? All at once! bugs as well and I would say likely would die off the same way core support gets removed. That puts a lot of burden on the maintainer, to keep fixing 8.x-4.x, 8.x-5.x, etc. Any security fixes will only be released for the supported versions.Īlternatively a contributed module or theme may consider opening new branches for each core compatibility change. I would say that is fine as long as you only drop support for core versions that are not supported anymore (out of the one year support period), because sites should not be running those anyway. Keeping Drupal 8's one year security support for minor versions in mind, that also means that you would force people using your updated code to update from a Drupal core version that is otherwise security supported just to receive bugfixes as well for the module. While Drupal 8.7 may be backwards compatible to Drupal 8.6, once you start using the new things from Drupal 8.7 you are not compatible with lower version numbers anymore. If you closely follow new core APIs, that also means that you keep updating the required core version number for your code. However it could lead to problems for users of modules and themes. This is not a problem at all if it is about your custom code and you have full control over the site being deployed to. As shown, the simplest case is the module keeps releasing versions of its own with new features and bugfixes (those are the gaps in numbers between versions shown), while it also updates regularly to new core APIs in the same stream. This sounds good in theory, however it is worth thinking about a bit. So theoretically contributed modules and themes and custom code could follow this update process:Ĭontributed module that keeps up with core updates Keeping module/theme/custom code up to date Ultimately this will lead to an easy and relatively small upgrade path to Drupal 9, because Drupal 9 will mainly be updating dependencies and cleaning up our codebase by removing deprecated APIs. ![]() This way the upgrade effort is spread out from one big upgrade to several smaller ones for site owners and contributed project developers alike. It hopefully also means that modules and themes get updated with the new better APIs. We can improve the version people actually use while creating the next version. We get our improvements into user's hands much faster this way and also get validation of the new additions and changes faster. This means that Drupal 9 is built step by step in Drupal 8 and so large parts of it are already running in production environments. What does that mean? Drupal 8 allows new backwards compatible changes and additions as well as provides ways to mark outdated functionality as deprecated. Instead of working on Drupal 9 in its own confined space, we work on it within Drupal 8. With Drupal 8 however, we adopted a key change in our process. module compatibility Drupal 9 gets built in Drupal 8
0 Comments
Leave a Reply. |