Backwards Compatibility: Burden & Benefit
The benefits of backwards compatibility (BC) are clear: no users are left behind. Which leads to higher adoption rates because you're often getting new features and you always have the latest security fixes.
Of course, that's easy when you have a small API surface (as Nate Haug once said: "the WordPress API has like 11 functions!" — which is surprisingly close to the truth). But Drupal has an enormous API surface. In fact, it seems there's APIs hiding in every crevice!
In Drupal 8, we have experience with some extremes:
- the BigPipe & Dynamic Page Cache modules have no API, but build on top of other APIs: they provide functionality only, not APIs
- the REST module has an API, and its functionality can be modified not just via that API, but also via other APIs
The first cannot break BC. The second requires scrutiny for every line of code modified to ensure we don't break BC. For the second, the burden can easily outweigh the benefit, because how many sites actually are using this obscure edge case of the API?
We'll look at:
- How can we make our modules more evolvable in the future? (Contrib & core, D8 & D9.)
- Ideas to improve this, and root cause hypotheses (for example, the fact that we have API cascades and not orthogonal APIs)
We should be thinking more actively about how feature X, configuration Y or API Z might get in the way of BC. This session is only a starting point; we should continue discussing in the hallways and during dinner :)