Evolving Our Commitment: An updated Support Timeline, new Roadmap, and unified Release Policy

Today, we're excited to announce significant updates to how we communicate the future of Silverstripe CMS. We've been working to clarify our long-term vision and commitment to the product, and as part of that effort, we're introducing a brand-new product roadmap and a clearer support timeline, as well as a unified release policy that consolidates our previous major and minor release guidelines.

To further clarify how we communicate, we've also updated the language used to describe the different support phases that versions of Silverstripe CMS are in during their lifecycle. We haven't changed the level of support that we provide to you, we're simply making it easier to understand the support we're providing.

Our goal with these changes is to provide even greater predictability and transparency for our users and developers, ensuring you have the information you need to plan your projects and stay up-to-date with the latest from Silverstripe CMS.

Charting the future: Introducing the Silverstripe CMS roadmap

We're sharing a clear roadmap for upcoming versions of Silverstripe CMS. This roadmap is a living document that outlines our plans for the product, giving you a glimpse into the exciting features and improvements we're working on.

Our initial roadmap highlights include:

• Performance improvements: Focusing on enhancing overall CMS performance.
• Last saved: A feature to help editors track how recently a page has been saved, reducing the risk of lost work.
• Duplicate blocks: Simplifying content creation by allowing easy duplication and movement of blocks across pages.
• Accessibility improvements: Dedicated efforts to enhance the accessibility of the CMS itself.
• In-CMS user support documentation: Providing in-context help to empower users.

View the Silverstripe CMS Roadmap.

A clearer view: Our new support timeline

We understand the importance of knowing how long a Silverstripe CMS version will be supported. And we've listened to your feedback that our old support timeline was confusing.

To make this information more accessible and understandable, we've introduced a new, easy-to-read support timeline table. While our support commitments haven't changed, the way we present them has been significantly improved for clarity.

This new table outlines the status, support length, release date, partial support start, and support end for each Silverstripe CMS version, including upcoming releases. You'll find details for CMS 5, CMS 6, and even the planned CMS 7.

View the refreshed Silverstripe CMS Support Timeline.

Making it plain: Standardising our support terminology

To make our support commitments even clearer, we've updated the terminology we use to describe the different support states for Silverstripe CMS versions. This is mostly a language change to improve understanding; the actual level of support we provide remains unchanged.

Here's a breakdown of the updated terms:

• "Bug and security fixes" is now "Full support"
• "Security fixes only" is now "Partial support"
• "Active development" is now "In development"

Many people found the old terms confusing, particularly "Security fixes only", because that only offered support for high and critical vulnerabilities, and not low or medium ones.

Streamlined Guidance: Our unified release policy

To further simplify our communication, we've condensed our previously separate major and minor release policies into a single, comprehensive unified release policy document. This unified policy provides clear information and definitions on release types, their cadence, scope, and support lifecycle, all in one place.

We’ve also added some definitions of terminology used in the policy document so it’s clear what we’re talking about, e.g. when we say “Silverstripe CMS release” vs “Silverstripe CMS version”.

In unifying the major and minor release policies we aren’t making any significant changes to our commitments or anything about how we release or support Silverstripe CMS. The goal is to communicate our existing commitments more clearly.

Note there is one very minor change from the old policies - previously in the minor release policy we said that we would only ship critical impact bug fixes after a minor release candidate was tagged. We’ve updated this to remove the word “critical” to enable fixing lower impact issues at this point too.

View the unified Release policy.