Click here to watch Making big changes.

Each major release of Drupal has introduced a few significant architectural changes that require updates throughout the Drupal codebase, from the form API in Drupal 4.7 to the field API and overhauled database layer in Drupal 7. Such changes accelerate Drupal's growth, but they also carry risks:

• Major changes often spawn long, difficult-to-follow issue queue discussions that make it challenging for contributors to participate.
• Some of these changes also introduce significant technical debt that negatively impacts other development and the release cycle as a whole.
• Patches that touch a lot of the codebase are difficult to reroll, and difficult to roll back if something goes wrong.
• Large patches are furthermore difficult to review and can cause contributor burnout.

Drupal 8 has more "big changes" than any previous release. Over the course of the release cycle, we've learned some lessons about what works for making these changes--and what doesn't. I'll summarize some of these lessons, both from Drupal 8 initiative retrospectives and from my own experiences (including merging Views into core and converting blocks to Drupal 8's new plugin system). We'll discuss how we can make the big changes of the future more successful, and how we can make sure Drupal 8's lessons don't go to waste.