How many Drupal Core change records (CR) has there been over the years? Is it a manageable amount for contrib maintainers? How many are about something new or deprecated? This is what it looks like since 2018. For visual effect I grouped CRs in 4 buckets:
- deprecated: code that will be going away at some point.
- adjust: existing API with new behaviors, rename.
- new: a whole new api, subsystem, features.
- other: internal changes, policies, or other non-detectable changes.
That's 3119 change records in 8 years, slightly more than 1 change record per day. One remarquable thing is that we have more deprecations than API additions. The API surface of core is shrinking slowly but surely, this is in line with the new Drupal Core strategy. This will be a recurring topic: the community setting out to do something and we can see it working. Pretty boring as far as marketing and hype goes, but it's a testament to the maturity of the project and the community. Of course plenty of other efforts don't work out, at least here we have proof some of the important ones do.
Now back to our contrib maintainers, 1 change record per day sounds overwhelming. Luckily Drupal Core is big and not every change record will impact every module. We have 9474 active modules compatible with the supported releases of Drupal Core, and 1921 modules are concerned with at least one of the 225 CR for the upcoming Drupal 11.4.0 release. Most CRs do not require an immediate change thanks to our backwards compatibility policy. A deprecation only becomes a problem when the contrib module needs to support the next major version, where the deprecation are removed. To ease the impact of deprecations we've even committed to removing disruptive deprecations in Drupal 13 (released in 2028) instead of Drupal 12 to give more time to contrib and projects to adapt.
All this to say, most of the time, a Drupal core release is a non-event for contrib. The only signal we can see from contrib is a 20% increase of contrib releases in the week after a Drupal Core release, but it's not the same modules that consistently release in sync with core! They're different modules every time, and mostly the modules that are not concerned with the change records for that version.
I think the next few posts will be the same: I'll be providing data to corroborate what we've already put in place… with graphs. CRs, deprecation policies, backwards compatibility layers, all worth it! Only thing I would suggest is improve the structure of change records so we can pick up the code changes more easily and help derive rector rules from them. Because as we'll see in the next post, having a rector rule on a change record is a massive help to contrib, we go from 67% of modules picking up a change to 98% when a rector rule exists.
Next we'll go more in details about what happens in contrib, when does contrib follow core changes, do they release proactively or wait for major core releases to ship deprecations removals? and how many of the 3119 change records even apply to contrib modules?
Thanks to Palantir.net and Vardot for sponsoring my work in the Drupal community.