Agency oriented TYPO3 lifecycle (AKA LLTS)

Agency oriented TYPO3 lifecycle (AKA LLTS)

I initialized this topic without a core member support (yet) from the discusson about TYPO3 v9 requirements (https://decisions.typo3.org/t/minimum-requirements-for-typo3-v9/) and I think that one point that sticked out from this discussion is that the whole thing about the release and the requirements is not agency oriented or agency friendly. Therefore I propose a new, additional, TYPO3 lifecycle of 3 to 5 years called long long term support (LLTS).

Impact

The main impact is on the TYPO3 core team, since they would be the ones to have to support TYPO3 versions up to 5 years old (or maybe more, if you would consider releasing an extended long long term support or ELLTS). Also, in order to relieve the core team from some work, only odd or even versions of TYPO3 could get an ELTS and maybe only every second LLTS version gets an ELLTS.

Pro

  • long long term versions are more attractive for companies that have to plan their software schedules years in advance
  • if needed, a specific feature can be backported into a minor version (see Ubuntu and their minor versions)
  • instead of providing (E)LTS support for 1,2 or 3 TYPO3 versions (as it was the case until march 31st 2017), you could reduce it to maximum 2 versions
  • new versions shipped to companies have noticeable added value
  • agencies with lots of TYPO3 instances have enough time to update to newer versions of TYPO3 and/or Linux/Windows distros if needed without jeopardizing the security of their customers websites
  • tech freaks can continue to “play around” and make a new fancy product

Con

  • increased maintaining effort for the TYPO3 core team

Remarks and notes

Organizational

Topic Initiator: Tizian Schmidlin st@cabag.ch
Topic Mentor:

Thank you for bringing up the topic. I answer with two questions:

  1. In what periods are customers willing to pay for a migration to a new version?
  2. How long needs the overlapping time frame of two LTS versions to be to get it done for multiple customers?

Now some considerations of decoupling. The current discussion reveals that the needs of core developers and agencies are not as independent as they should be.

In the ideal world the core developers should always be able to work with the most recent software, to keep TYPO3 up to data in competition with other CMS. They should not be handicapped in this, by the version requirements of agencies.

On the other end the support of LTS needs to be long enough, that the business model of the agencies keep working and stay in compatibility with the LTS versions of the major Linux distributions.

Thank you, Elmar, for your feedback.

To answer your questions:

  1. From a human point of view, I would not be very happy to pay my web service provider (aka agency) a day or two of work every 18 months. I have a very strong feeling about TeamViewer doing this and therefore I can relate to any customer with the same issue. 36+ months is way more reasonable.
  2. From experience, talking about 300+ TYPO3 instances takes approximately a 100 weeks, so at least two years.

I totally agree with you on the other points.

I don’t have any good solution right now but from an agency point of view, they are still, for many, upgrading from v6.2 to v7. I know many of them only starting to do so for some websites.

As we know v7 has reached end of standard bug fixes and is now in “important and security bug fixes”. This is exactly the point in time where most agencies are actually ready with v7 or for those who had to “fight a bit”, starting to migrate to v7.

Regarding v8 there are still a few edges which need to be polished a bit but above all, quite a lot of extensions are not yet v8 ready, hurdling or preventing the migration. Furthermore, migrating straight from v6.2 to v8 (even with a small jump on v7) is quite challenging so I’ve the feeling that most agencies will not skip a LTS version but migrate from LTS to the next one in most cases.

This means 2 migrations to be sold to the customer and certainly not migrating from 6.2 to v7 and 1 year after that migrating again to v8 to try to regain some way in the standard TYPO3 release cycle.

Add to this, as a customer, that getting a v7 when the v8 is out is… well… possibly not very easy to understand.

What’s wrong with the existing ELTS program? Because from my experience you can have exactly what you are asking for already. It’s been available for TYPO3 4.5 as well as 6.2 and I would hazard a guess that it will be available for 7.6 once that reaches the EOL mark.
The only difference I can see to your proposal is that the existing programs cost money and you would like the Core team to provide this service for free.
Playing the devils advocate I’d say we are talking about customers which are not willing to include <100€/Month&Site for maintenance in years 4 and 5 of their budget plan or are not willing to pay the agency to put in the work of upgrading.
If I understand correctly the proposed solution to this dilemma is finding somebody (the Core team) to give them option 1 for free?

2 Likes

If we take the example of PHP 7.1. If we put in into LTS 9 the time frame from enabling PHP 7.1 in Redhat and Ubuntu and the end of LTS 8 is likely to short to do the migrations.

This introduces a dependency from the need of agencies that would not be given with a longer support of the LTS versions.

Thanks @masterofd for opening the discussion for this topic.

From a historic point of view, we had the 6-month-release cycle which we introduced with 4.3/4.4, and after 4.5 LTS and some further releases, we actually had to maintain 5 different stable versions, which is truly very difficult, considering all the minimum requirements (PHP version) where we also had some regressions due to PHP 5.2 support back then, so each backport should be considered and reviewed very carefully. Back then 6 months was considered too short to update, but 1.5ys seemed fine ;).

From a core team perspective, it’s already hard to developer a future version while fixing bugs in existing stable versions, having most of the core team doing this maintenance in their spare time. Meaning: Core devs need/should have all supported versions running somewhere to test everything.

Additionally, I have quite some extension authors that wanted/needed to keep compatibility with 6.2 LTS and 8 LTS, so it’s not just a core team responsibility and this needs to be kept in mind.

IMHO the biggest strength of the current release strategy for an agency lies in the predictability of the next LTS release: You know, you have a new project which will be finished 2 months after an LTS release, so you could use the next version instead of working with the previous LTS and then need to upgrade.

So, going back to your proposal, the biggest pain point I see for agencies / devs / admins is that the updates from LTS to LTS are still too “big”, too complicated and not as easy as just “clicking a button” (yes, I’m dreaming).
I think we’ve done better since 4.5->5.2, but still it’s not as easy as it could be. Also, core development still seems for me as “cleaning up” the big mistakes we did in 4.x branch (or did not know better back then), leading to massive breaking changes. The PHP7 bump / requirement is difficult for our projects to update from 6.2 to 8 directly (due to server updates in between). That also comes from the issue that there were (and still are) so many ways to do it in the previous versions while we go further in pushing “best practices”.

So: If the core gets better in fixing most of the currently open tickets, solving important conceptual problems and the update strategy is improved (e.g. code migration, DB migrations), I think agencies could benefit from easier updates, instead of “staying in the past” and that should be the actual goal.

If people stay with an old TYPO3 version or a 5ys LLTS then extensions will be a problem (most of the time, I’ve seen that) and that won’t make the update easier to the next-next-next version then.

Basically my message is this: Let’s look at the root cause(s), not a symptom why this is a problem for agencies / admins / hosters.

2 Likes

I think, Helhum brought up the points pretty straight, which makes agencies stay with older versions: these are the many (extension-)breaking changes. Benni mentioned that too here.
So the way to go is, avoid (extension-)breaking changes as far as reasonable. (The changes from 4.5 to 6.2 were really painful, 6.2 -> 7.6 already was better, and AFAIR 7.6 -> 8.7 gots again better, but as always and everywhere: try to improve, if you just aim to maintain the current state you will get worse).
Concerning the topic of php7.1: for me personally it would be totally fine. But I guess there are a lot of agencies which find that challenging, not to forget the big enterprises with clear and strict obligations which OS can be used and which (if any) third party repositories.
That’s the reason why I am clearly against raising minimum requirement to 7.1 vor TYPO3 v9.

Regarding the discussion about development pace. We have the funny situation that people cheer on us Core team with these sayings:

  • 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

As you can see those expectations can not be more contradicting.
The usual thing is to find the compromise and what Helmut Hummel suggested in this post seems a good compromise to serve all stakeholders.

1 Like

For “extension breaking changes” see my reply in the other thread about release cycles: Are the minor releases actually worth it?

Personally I think the problem is a stacking of LTS products. The OS is an LTS version, supported for 5 years. The OS has the policy that the tools they ship will stay with the same version throughout that period. This means that products using that OS will have to support those versions too. If the product support a range of OSs it needs to support the versions of the tools from all those OSs.

  • linux distro X has PHP 5.3.7 and will be supported from 2014 to 2019
  • linux distro Y has PHP 7.0.9 and will be supported from 2016 to 2021

During the overlapping time the product cannot use features from PHP 7 but also no features from 5.3.7 that were removed in 7. If that product is released in 2016 and will also be supported for 5 years then it isn’t feasible that in 2019 the product is rewritten to use feature from PHP 7. So it will stick to features from PHP 5.3.7 until 2021.

If you combine that with more OS version and more tools (several database, graphics tools, libraries) progress has come to a stop. Only if application will require newer versions the OSs are forced to provide support for those.

Can we introduce non-breaking feature releases? Sure, but this wouldn’t cause progress. Suppose we didn’t make TCA renderType mandatory, didn’t drop support for TCA script property, and kept using ext_tables.php in frontend.
Experience shows that a deprecation log doesn’t prompt extension authors to adapt to a new situation. Only if a feature is dropped or made mandatory there will be a change.
If we don’t drop old features and options we still need to maintain that codebase. With the ever lasting lack of manpower we simply cannot afford that.

Summary

We need to clean up the code base to be able to maintain it. Therefore we need to drop features from time to time. There are LTS versions with a reasonable free support period. For longer support a paid ELTS program is available (with enough demand this can be extended even more probably).
Extension will either follow new developments and drop support for older core versions, or keep using older cores and only support newer core versions at a late moment. Their time is also limited.

2 Likes

This topic was automatically closed after 28 days. New replies are no longer allowed.