Backwards Compatibility: Burden & Benefit

published on March 22, 2017

In my job at Acquia, I’ve been working almost exclusively on Drupal 8 core. In 2012–2013 I worked on authoring experience (in-place editing, CKEditor, and more). In 2014–2015, I worked on performance, cacheability, rendering and generally the stabilizing of Drupal 8. Drupal 8.0.0 shipped on November 19, 2015. And since then, I’ve spent most of my time on making Drupal 8 be API-first: improving the RESTful Web Services support that Drupal 8 ships with, and in the process also strengthening the JSON API & GraphQL contributed modules.

In the process, I’ve learned a lot about the impact of past decisions (by myself and others) on backwards compatibility. The benefit of backwards compatibility (BC). But the burden of ensuring BC can increase exponentially due to certain architectural decisions. I’ve been experiencing that first-hand, since I’m tasked with making Drupal 8’s REST support rock-solid, where I am seeing time and time again that “fixing bugs + improving DX” requires BC breaks. Tough decisions.

In this talk (which will be a core conversation at DrupalCon Baltimore), I analyzed the architectural patterns in Drupal 8, and provided suggestions on how to do better. I don’t have all the answers. But what matters most is not answers, but a critical mindset going forward that is consciously considering BC implications for every patch that goes into Drupal 8!

Not thoroughly considering new interfaces (API surface) risks making the software unmaintainable!

Preview:

Slides: 
Slides with transcript
Conference: 
Drupal Dev Days Seville 2017 + DrupalCon Baltimore
Location: 
Seville, Spain + Baltimore, USA
Date: 
Mar 22 2017 - 15:30
Duration: 
50 minutes
Extra information: 

See https://events.drupal.org/baltimore2017/sessions/backwards-compatibility-burden-benefit + https://seville2017.drupaldays.org/sessions/backwards-compatibility-burden-benefit.