Revising our approach to major release

We released Silverstripe CMS 4.0.0 in November 2017. That’s almost 5 years ago. Today, thousands of projects are using Silverstripe CMS 4 delivering value to millions of content authors and web visitors. Since its release, the open source team at Silverstripe has fixed thousands of bugs, patched dozens of vulnerabilities and added several new capabilities.

Silverstripe CMS 4 is still fundamentally a great platform to build websites and web applications. It continues to be architecturally sound. However, over the last two years, we’ve started to observe some dynamics that lead us to conclude that we need to start looking at how and when we will publish the next major release of Silverstripe CMS.

Today, we are publishing a Request For Comment (RFC) on a new Major Release Policy proposal.

In this blog post, we want to explain:

• The reasons why we are proposing the Policy,
• The necessities driving this new approach to major releases, and
• What it will mean for the Silverstripe CMS community.

Above all else, we are seeking your feedback on the proposal so that we can make sure it accommodates the wide and varied needs of the Silverstripe CMS community.

Keep calm and carry on ... CMS 5 will NOT be like the Silverstripe CMS 3 to 4 upgrade

We’ve heard countless “war stories” of 3-to-4 upgrades that went wrong. Many of those stories came from our own developers and clients.

In hindsight, we substantially underestimated the amount of work needed to upgrade a Silverstripe CMS 3 project to Silverstripe CMS 4.

We want to make one thing crystal clear: Upgrading from Silverstripe CMS 4 to Silverstripe CMS 5 will be a relatively easy process.

The simple reality is that Silverstripe CMS 3 and Silverstripe CMS 4 were two substantially different products. This is not the case for CMS 4 to CMS 5.

With CMS 4 substantial architectural changes needed to be introduced, such as the namespacing of the code base or the refactoring of the assets system.

Silverstripe CMS 4 remains architecturally sound. Therefore, Silverstripe CMS 5 will be an iteration on CMS 4 rather than a revolution.

Silverstripe CMS 5 will include some breaking changes, but most of those will be “mundane things” like upgrading dependencies or removing deprecated APIs.

That’s why we feel comfortable promising that upgrading to Silverstripe CMS 5 will be a relatively easy process.

Our recommendation, to anyone who has Silverstripe CMS 4 projects scheduled over the next few months, is to maintain your current plan and simply carry on without delay.

So why are we proposing a new Major Release Policy?

Since releasing Silverstripe CMS 4.0.0, we’ve published 10 further minor releases of CMS 4 and we are about to release an 11th.

Silverstripe CMS follows semantic versioning. In theory, our minor releases should be backwards compatible … and for the most part they have been. However, we’ve had to occasionally “bend” the definition of semantic versioning.

For example, in the Silverstripe CMS 4.4.0 release, we had to make substantial changes to the assets system to enable permanent file URL, and developers upgrading their project had to run a migration task to put their files in the right place. Or we had to fork PHPUnit 5.7 to support later PHP versions and had to add “dual-support” for PHPUnit 9.5 in the Silverstripe 4.10.0 release.

These kinds of changes are inevitable to support the latest version of essential dependencies.

Trying to deliver them in minor releases is very complex and requires us to resort to hackish solutions to avoid introducing breaking changes. And in some cases, it’s literally impossible and we have to sneak in some breaking changes in minor releases.

So while in most cases, Silverstripe CMS 4 projects could be upgraded to the latest minor releases with little effort, occasionally developers had to account for unexpected changes.

Providing certainty to Silverstripe CMS project owners

Our primary objective with this policy proposal is to provide certainty to Silverstripe CMS project owners by adopting a major release cadence that is sustainable and manageable.

We want project owners to be confident that when a minor release ships, it’s a true minor without any breaking changes. We want new major releases to:

• occur at predefined intervals
• provide a clear support schedule for older major releases, so project owners can plan their upgrades accordingly.
• be iterative rather than transformative.

What this means is that Silverstripe CMS major releases will focus more on upgrading dependencies or paying down technical debt, and less on introducing new architectural constructs.

Practical implications of this proposal

Our policy proposal is calling for a new Silverstripe CMS major release every two years. Older major release lines would be supported for two years following the release of a new major.

This proposal would align Silverstripe CMS with many of the third party dependencies it relies on:

• PHP releases occur once a year in late November,
• PHPUnit releases occur once a year in December to add support for the new PHP releases,
• Symfony releases new majors every two years.

The proposed change of introducing a scheduled two-year major release cycle, will make it easier to upgrade Silverstripe CMS dependencies in a clean and predictable way.

We want to stress that this new policy is a proposal, at this stage. Because this is a substantial change to the way we release Silverstripe CMS, we need feedback from the Silverstripe CMS community. Your feedback will ensure we best understand the full impact of this change and to validate our stated policy objective.

What’s next and how to get involved?

Our RFC has now been published on GitHub for all to review

The RFC highlights key principles that we think should guide the policy and some specific questions we wish to answer.

We encourage all Silverstripe CMS community members to carefully review the RFC and provide feedback on the key principles, answer the questions or seek clarification on ambiguous points.
We will also be reaching out to Silverstripe partners and Silverstripe clients for their feedback.

Once we’re confident that there’s broad agreement on the key principles, we’ll draft a formal policy that will be added to the Silverstripe CMS documentation. We're hoping to have this process wrapped up around early July, 2022.

At this point the policy will then be formally adopted, and we’ll be in a position to plan an approximate release date for Silverstripe CMS 5 and to start identifying specific changes that should be targeted to this release.