Update 28/09/2018: Corrected the roadmap graphic to show the updated support timeline for 3.7+.
In December 2016, we introduced the concept of Long Term Support (LTS) releases to provide more certainty about how long different SilverStripe release lines will be maintained and we also introduced a distinction between different release phases. This is all visually communicated on a timeline in our roadmap.
Since the 3.x release line has changed phases and the 5.x release is getting closer in this original plan, we felt it was time to give you an update on where we’re at.
SilverStripe 3.x support ending in 2020
The 3.x release line is marked as LTS and in June this year it transitioned into ‘limited support’ meaning that it now only receives critical bug and security fixes, and fixes for important issues introduced by new browsers. By the time 3.x. goes out of support in September 2020 you should have upgraded to SilverStripe 4.x or 5.x (more on 5.x below).
Also note that in December 2018 PHP 5.6 is End-of-Life. From this point, unless you have a way of getting extended support for PHP 5.6, you should upgrade to PHP 7.1. which requires at least SilverStripe 3.6.
Nearing the first anniversary of SilverStripe 4.x
We’re nearing the first anniversary of the 4.x line which was first released in November 2017.
Thanks to feedback from our global community, we’ve spent the last year stabilising and improving the 4.x release line with months of developer effort dedicated to providing great upgrade tools and docs. We’ve also added support for public webroot, support for versioning and archiving all the things, and safer caching and draft defaults.
Behind the scenes, we’ve been working hard to create a design system to support our increased focus on new user experiences, including content blocks. A lot of work has also gone into getting 4.x into the hands of New Zealand Government clients under the Common Web Platform (CWP) through the CWP 2.0 release. This included upgrading and improving the 50+ supported modules contained in the release, which also benefited the wider community outside of CWP.
SilverStripe 5.x: Taking time to get it right
SilverStripe 5.x was due to launch in Q4 2018, one year after 4.x. But given the recent focus on 4.x, we’ve not focused on API-breaking core features as much as expected, lessening the need for a major new version. Frequent major releases get new APIs and features out faster but also increase the burden on developers and module maintainers to upgrade more often.
Here's the full picture in our roadmap. Note that the cross-hatched support timelines are tentative.
Regardless of where this discussion leads, we’re committed to our existing Long Term Support (LTS) plan for the 4.x release line. We’ll have at least two years of ‘limited support’ after 5.x is released (and well after this release date is announced) allowing everyone ample time to coordinate upgrades. In the meantime, this doesn’t mean that new features and APIs need to wait.
While we stand by our commitment to semantic versioning, the core team is discussing better ways at getting new APIs into the hands of early adopters. This could potentially involve new opt-in module releases (rather than new core recipe versions) or marking some APIs as internal in stable releases to strike a balance between providing a stable editing environment for authors, while allowing devs to plan ahead.
For core CMS UI changes, we’ll be looking into creating parallel implementations (similar to the gradual introduction of a React-based asset section SilverStripe 4.x) which both devs and authors can choose to use before the changes become the main implementation. This is going to be an important factor for the upcoming React/GraphQL-based GridField.
Achieving more clarity on minor releases
While we’ve created more predictable phases for release lines in our roadmap, the cadence of minor releases within those (e.g. 4.0, 4.1.) and their support status was not well defined. Based on discussion we’ve now come up with a clearer definition:
- The End-of-Life (EOL) for minor releases of a major release in “active development” or “full support” will be announced at least six months in advance.
Until then, they will receive security fixes and critical bugfixes. Upgrading to newer minor releases should be painless due to semantic versioning and should not require changes to your project code. And note that while there are no commitments around patch releases (e.g. 4.1.1, 4.1.2), we’re aiming to get bugfixes into the hands of users and devs at least once per month. The details of this are documented in our release process for core modules, and you can subscribe to the EOL announcements on our forum.
There are different agreements in place for the quarterly releases for customers of the New Zealand Common Web Platform (CWP). Please refer to the CWP Release Management process documentation.
When it comes to the constantly growing puzzle of creating digital experiences, we recognise that a web framework and CMS are only one piece.
We’re heavily investing in APIs allowing for Headless and Decoupled CMS use cases through the GraphQL module and content blocks are continuing to be the focus point for CMS UX innovation, with faster authoring through inline block editing being built right now, and more complex layout blocks next in the pipeline.
Beyond this, we’re concluding a research phase which will lead into more investment around making SilverStripe a viable platform for broader digital experiences beyond simply authoring content – stay tuned!
We‘ll shortly be asking for the community’s feedback in our annual survey. If you’d like to be notified when this survey is released, please provide your name and email below.