This topic is inspired by the answer of Helmut Hummel in the minimum requirements topic (https://decisions.typo3.org/t/minimum-requirements-for-typo3-v9/149/18)
and the topic auf the LLTS (https://decisions.typo3.org/t/agency-oriented-typo3-lifecycle-aka-llts/169/9).
I’ll start with a quote:
- TYPO3 develops way too fast, our devs can’t hold pace.
- TYPO3 should be more stable… I want 10 years of support for a version (sic!)
- TYPO3 does not invent fast enough, modern techniques are not adopted fast enough
At first all these statements sound contradicting. But I think part of these problem is the current release policy.
TYPO3 develops way too fast, our devs can’t hold pace.
I disagree, that the development is too fast but I totally agree that the pace is too high. Especially for those that cannot adopt new versions in time for whatever reasons. This does apply mostly for the minor versions. The adoption rate for minor versions like 7.0-7.5 is very low due to several problems, one of them being a too high pace.
TYPO3 should be more stable… I want 10 years of support for a version (sic!)
Yes, everybody wants this. And TYPO3 is pretty stable at all. I think whenever people refer to stability, they first of all think of breaking changes. While these changes are necessary, you can mostly struck by them during minor version upgrades. During the last 4 years I work as a freelancer, I was never ever asked to perform a minor version update. Neither was that requested by the client itself, nor could it be sold. Dealing with breaking changes every two years is simply less expensive than doing it every 3 months.
TYPO3 does not invent fast enough, modern techniques are not adopted fast enough
To be honest, I never heard this from a customer. This is developers speaking. And it’s not a problem at all. I am a developer myself and like to embrace all the good changes that make my life easier. However, there have been very few changes in the past that made such an impact so that a client could have had a desire to upgrade. One example of such a thing would be Doctrine DBAL for a client with a desire to switch from MySQL to MSSQL. Let’s face the ugly truth, the clients do not recognize the Form-Engine rewrite in the first place. Neither do they realize the switch from Ext-JS to jQuery.
I don’t know how many core developers and contributors have to actually sell their software but I do more and more think that it would be good to do that as a role play game for every released version. Ask yourself, why your customer should do the switch from 7.3 to 7.4. How much is the benefit compared to the impact of breaking changes? Is it possible to sell 4 small features in time when there is a need to adjust dozens of hooks.
It’s as simple as that. There need to be enough improvements to justify the amount of time given and money spent to do the minor version upgrades instead of just using the LTS versions.
What if we treated TYPO3 as a product?
This question sounds strange. It implies that we do not treat TYPO3 as a product and that’s what I mean. Seriously.
Let’s have a look at why there is a demand for software updates anyway. Mostly it’s clients having feature requests. It’s really simple. You get a call from your client and 99% it’s about “can we have this or that, it would make our lives easier”.
I wonder why we don’t have a look at that in the first place and see which nice features can make it into the next version.
I know, it’s open source and part of that is, that people work on whatever they like. Still, I am sure that there are enough feature requests that are lovely enough to find someone to work on.
So, instead of releasing software by date, why not release software by milestone and set a soft deadline? This would be much easier to sell and it would raise the joy about each new version a lot.
One could finally sell features long before an LTS version is released.
- Next version contains the frontend editing, for sure.
- The version after we have native routing, really!
Currently this is not given, making people struggle to sell new TYPO3 versions beyond the aspect of security.
Does semantic versioning help?
I am sure about that.
See the statement of Helmut Hummel about that. It really lowers the burden for everyone to not have breaking changes in minor versions.
For the ones that sell the software and for all the extension developers that can focus on the next major version instead of making something compatible for a specific minor version.
Please let’s reevaluate the current release cycle that is much more date than feature driven and make every release worth it again.