Interesting how different perspectives can be, isn’t it
Also interesting, that both is correct. Keeping up with latest developments to benefit from every new feature, is pretty tough to say the least.
On the other hand there is so much legacy code that definitely needs to be tackled (removed).
The only way to resolve this, would be to have releases with new features without any breaking changes. In fact the initial idea of implementing a new release cycle was to switch to “rolling releases” at some point. Meaning that anybody can easily update to get new features but certain states are kept as LTS for those who fear issues with new releases with features. One key word in the discussion back then was “semantic versioning”.
What we implemented now however are LTS releases that only receive bugfixes and every. single. release. with new features comes with breaking changes. This puts a big burden on extension developers but also end users.
Semantic versioning? We don’t have it. It is something TYPO3 still heavily differs from the composer world (aka pretty much the rest of the PHP community).
The release policy we started with 7.0 and continued until 8.7 was great and we achieved a lot. But now it is time to re-visit an re-think the strategy whether is still fits our needs and the needs of the TYPO3 community as a whole.
Therefore my suggestion would be:
- Raise minimum requirements with 9.0 as much as is reasonable, which would mean make PHP 7.1 a minimum requirement.
AFAIK PHP 7.1 has longer support (is kind of LTS) and has some very useful features we could use to modernize and harden our code base.
- Don’t pay too much attention to distros and what they support, because TYPO3 7LTS (comes with PHP 5.5 support) is supported until beginning 2018, 7ETLS until mid 2020. TYPO3 8LTS (PHP 7.0 support) is supported til 4/2020, 8ELTS until 2022! Users fir focus on long support times and stable versions can still validly use these versions
- Change the release policy to allow features to go into 9.x LTS after LTS is released and continue in short release cycles with 9.x+1 with features and deprecations only. After ~1,5 years, remove the deprecation and release 10.0 with the same feature set as 9.x at this point and raise minimum requirements as needed. repeat.
This is more or less how Symfony handles it and I consider this a solid release strategy.
- Finally implement semantic versioning
- Expand the time a TYPO3 version can be used without breaking changes
- Too many people might stick to LTS
However this risk can be greatly mitigated by the fact that updating to same major version releases are (other than in the TYPO3 past) hassle free (non breaking) and by delivering great features nobody wants to miss