Whenever we have security releases, they also contain the bugfixes and maintenance work that also happen to have landed in the branch since the release before.
As an example here is the change log for the 10.4.18 security release: TYPO3 10.4.18 Release Notes - get.typo3.org
In a project with a high demand for stability this kind of release raises a conflict between
- rolling out the security release to production as quickly as possible to mitigate any risks of attacks and
- scanning all other included changes for possible implications on the projects and thorough retesting.
This causes stress all while you’re typically busy with other work that was planned before. If security and bugfix releases were separated, we could roll out the security fixes quicker and with more confidence and we could easily take our time for planning, examining and testing the maintenance releases.
The way security fixes are handled and only merged into the branches shortly before the release should be kept as it is, to ensure the confidentiality of security issues. But for the security release itself a security release branch should be created, that is based on the release before and only the security relevant fixes should be cherry picked into it. The security release is tagged on that branch.
That applies to every major version, that is supported at the time. Currently for a security release that would mean creating 3 security release branches
9.5.31-sec (i wouldn’t include
This is what the 10.4.18 release could have looked like in terms of git branching:
In our website project we could do just that ourselves and fork TYPO3 on every security release and package just the security fixes, or include the security fixes via composer patches. But I think we are not the only project with that demand and the enterprise CMS TYPO3 could provide this.