For marketplace developers, choosing which Concrete CMS versions to support isn’t always straightforward. How do you strike the right balance between reach, maintainability, and future-proofing?
In theory, a developer could aim for compatibility all the way back to Concrete CMS version 5.7.0 (aka version 7.0 in modern terms), a core over 10 years old and no longer supported. Doing so would require careful handling of PHP versions from php 5.4 to php 8.latest, plus adapting to legacy autoloaders, routing, and vendor structures. Technically possible, but practically, is it worth it?
Short answer: No. Here’s why:
Personally I target recent Concrete CMS v9 releases, currently starting at v9.1.3. Its a sweet spot between old and new. I don’t deliberately block older cores like v8, but I also don’t test against them, it’s simply not worth the effort for negligible return.
Concrete CMS updates used to be risky, often breaking sites. But with the shift to a monthly release cycle updates are now smaller and lower risk, making it easier for site owners to stay current.
Some actively maintained sites remain on v8 for good reasons, typically due to custom themes or custom functionality that would be costly to upgrade. That’s why core security fixes are still provided for "legacy" v8.5.x, and some developers choose v8.5.latest as their minimum supported version.
I followed that path early on in Concrete version 9, when it was still stabilising. I had customers transitioning from v8 to v9, so I needed to support both core versions. But as new users adopted v9 exclusively I shifted my minimum support accordingly. Today, v9.1.3 is my baseline and I continue to review that as the platform evolves.
If you would like to discuss any of these thoughts, please start or continue a thread on the Concrete CMS Forums.