Backward compatibility: It's not a thing. That's been our party line for years. We allow ourselves to innovate by breaking APIs between versions. That has allowed us to evolve Drupal over the past decade, but also means a rather unpleasant duality: We can't really evolve the system in backward-compatible ways (because it's a stable version), but upgrading between major versions is always painful. Unfortunately, our architecture did not allow us to do anything better.

Much has changed, however. The cost to businesses to do a tear-down of their site every major release is getting more and more prohibitive. As core takes over more and more functionality from contrib, we can't rely on contrib to pick up the slack in inter-release innovation. With core releases getting longer and longer, the incentive for companies to invest in core is decreasing.

However, we've also made radical shifts to Drupal's architecture in Drupal 8. The large-scale shift to object orientation means it's easier than ever to improve the system without breaking backward compatibility. Do more, break less. That opens up the potential for us to solidly address the boom-bust cycle of core development and innovation, and break the mindset of "it's not innovative if you don't break APIs".

I am talking about feature releases within the Drupal 8 cycle, feature releases that are our focus rather than an after-thought. And with that, postponing Drupal 9 development until we know what it is we're going to do with it.

This session will lay out a vision for a new core development release cycle, one that is semantic versioning based and better balances backward compatibility, forward-compatibility, innovation, and incentives to contribute. If anything, it may well improve our ability to innovate rather than hinder it. It's a vision that we can and should embrace for Drupal 8 and beyond.