Minimum Requirements for TYPO3 v9

Hey Markus! No jokes over here :slight_smile:

Can you please make an example where security relevant fixes were NOT provided in “no time” by any of these vendors? Let’s look at the examples and discuss…

(Reason: I think that e.g. Debian is doing a great job with security updates, and I would always prefer them over a 3rd party repository unless I am building them on my own…)

I would also recommend to not use any 3rd party repositories, because they don’t provide you the guaranteed support that you get from OS vendors. For example, Dotdeb has been a one-man project for years (https://www.dotdeb.org/2017/01/27/php-7-1-dotdeb/). I actually never checked, but who is doing the releases while the maintainer is on holiday? (Besides this, I never liked it because of breaking changes that came in by mistake…)

3 Likes

I did not say that those do not provide fixes in “no time”. I defined it as a minimum requirement for “pro” hosting.

What I dislike a bit about those “super long fix promises” is that they actually provide, or try to provide, fixes for versions that are officially not supported anymore. That means that “someone” is sitting there and doing code changes based on finding of newer versions in old code. It is of course a nice service, because you as a hoster do not need to care.
On the other hand those distros grandiosely failed to adapt to the speed of webdev and provide current versions (specifically PHP) to their users. Remember the times of PHP 5.3.7? We had to support that sh*** in TYPO3, because Debian failed to provide updated packages in one of their distro versions, which itself was still “current”.
In that very case the issue was not about sec fixes, but about heavily need regression fixes in PHP.

So my point is that with those “pseudo-long-term” things you may not need to do so much testing yourself (like with other third party repos), but you shoot yourself into the knee on the other hand, because your are stuck in the past.
And if there is one thing on the Internet which really bites you in the end is being stuck!

The positive part for sure is that those distros are getting better in this regard and provide those possibilities.

A practical example why we use apache from third party: Because we run on 2.4.25 as we really need those tiny nice changes, which happened since 2.4.7 (whcih is shipped by ubuntu LTS). To name it: fcgi proxying via sockets. What a charm, what a speed, what an easiness of configuration.

1 Like

This post in on the PHP version in v9 only, not on db / browser.

tl;dr: keep php 7.0 support in v9

php 7.0:

  • php 7.0 is a major version that will be supported by a series of distros even after end of official sec-support from php team
  • supporting php 7.0 in v9 means people who upgraded to php 7.0 for a v8 upgrade don’t have platform issues if upgrading to v9
  • the php 7.1 language benefits are nice to have but no killer must-have features, we can live with the php 7.0 restrictions without crippling architecture too much
  • we should better use v9 to further declare_strict=1 more classes, this needs huge efforts anyway, php 7.1 features are secondary and could be skipped for a core version

php 7.1:

  • supported in v7
  • supported in v8
  • supported in v9 - there is no php 7.2 yet, anyway.

php 7.2 is not on the horizon, but even if released:

  • v7 already supports php 5.5->7.1, and if there is no killer breaking thing it 7.2, it may support that, too. -> v7 may evolve to support php 7.2
  • v8 will hopefully run on php 7.2, better chances than v7. that would be in-line with typo3 core traditions, if there is no killer that gives us tons of headaches -> v8 will evolve.

Thus, I’d opt to support v9 with php 7.0, 7.1, 7.2 (if released), and whatever comes later in the LTS cycle of v9, if possible. For v10, we can then raise minimum PHP version to probably at least php 7.2, and will still have a good transition for people upgrading from v8 to v10, which would be perfect for our release cycles.

Sidenote: We can happily keep ourselfs busy with actually using more php 7.0 features in v9 for 1,5 years of development from now on, than jumping on the php 7.1 train now - which would only add additional upgrade issues to projects. For v9: Embrace php 7.0 features in the core. For v10: Raise php requirement as needed, can be discussed if time is ready.

6 Likes

PHP: we need to look at what various Linux distros do. If their current version still uses PHP 7 (be it with patches from 7.1 or later) then we can’t really require a later version. Only if there are so important must-have features in PHP that we cannot live without a different requirement seems justifiable.

MySQL: simply look at what the PHP drivers support. With Doctrine in between we need to be more DBMS agnostic than before. If all supported DBMS support a feature we might be able to use it and only if it’s critically important we can require certain versions.

Browsers: only IE/Edge seems to stick with OS releases. We know the policy by MS (which was one of the main reasons to start with the LTS concept by the way) and so IE needs to be supported. Other browsers are self-updating, except for when used in certain enterprise environments. It’s hard to set hard version limits for browsers. It might pay off if we rely on a JS framework to take care of browser support for various functionality.

2 Likes

Hello again,

I tried to add all your hard arguments to the original post, divided in pro and cons. Additionally I added some research regarding distro / doctrine support.

I also added the Windows file path max length point on the PHP 7.1 part of things - as we would finally be able to get rid of these problems with PHP 7.1.

If you have more pro/con arguments (that I forgot to mention) just reply here.

One wish: If you think we should look at further information like distro support etc. please add that information to your post else everybody else must google it or take decisions based on guesses.

Thanks,

Susi

1 Like

Hi all

From business view, I absolutely vote for PHP 7.0. Agencies are not early adopters and will never be. We are finally happy to have a TYPO3 LTS version (whoose lifetime is too short in my opinion). To run an TYPO3 LTS it needs a server and as you can imagine, this runs on a LTS server distro as well. And not every server runs on Ubuntu Server.

So we need to keep the support of older PHP versions, at least as long as they are used in enterprise server LTS distros.

And please remember which customers bring money into the TYPO3 community. It’s probably the agencies which support TYPO3 through the Association, through the ELTS program etc. So it’s important to fulfil the needs of these customers and not just stick to the newest trendiest software versions…

Thanks and best regards
Lukas.

7 Likes

Personally, I opt for using PHP 7.1, if it brings a noticeable benefit / impact for our code base, otherwise stay with 7.0.

I have no strong opinion for the database stuff, I’d say we should stay compatible with what distributions most likely do / will support by their own (means, without the need of additional repositories).

For browsers, we should stay at least compatible with IE 11. There are still a lot of users that don’t run on Windows 10 and thus don’t use Edge.

About browser support, I agree with staying compatible with IE11.
I have no strong opinion about PHP/Database, so I agree with @anon56043406 : use the last cutting-edge technology only if it brings benefits you cannot live without.

Let me start with a Quote from the typo3.com Homepage

TYPO3 - Enterprise CMS
… TYPO3 enables customers all over the world to run and extend their applications according to their business needs.

Based on this quote, in my opinion the current discussion is too technical. There are for sure technical reasons, but in the end, enterprise market is what we aim for. In my point of view this is what it’s all about: Business needs. The discussion should therefore mainly focus on widely supported PHP versions in the most common Linux distributions.

Regarding “most common Linux distributions” we also have to consider one important thing which is often forgotten: We have 2 different markets to cover. On one hand we have a mass market where a Hosting Company is providing all the services for a huge amount of customers. On the other hand we have the enterprise market where companies are bound to a specific distribution as they have to comply to company wide regulatory requirements. And normally this is not Ubuntu for example.

So my vote in this discussion is pretty clear: Stick to PHP 7 for v9 as Jigal, Lolli and Stucki already proposed.

4 Likes

Regarding Martins argument about distro support I’ll add some facts for PHP on Ubuntu.

Ubuntu 18.04: Release 2018-04, EOL 2023-04, expected is PHP 7.2.x *¹
Ubuntu 16.04: Release 2016-04, EOL 2021-04, PHP 7.0.x
Ubuntu 14.04: Release 2014-04, EOL 2019-04, PHP 5.5.x
Ubuntu 12.04: Release 2012-04, EOL 2017-04, PHP 5.3.x

TYPO3 8.7: Release 2017-04, EOL 2020-03, PHP 7.0.x - 7.1.x
TYPO3 7.6: Release 2015-11, EOL 2018-11, PHP 5.5.x - 7.1.x
TYPO3 6.2: Release 2014-03, EOL 2017-04, PHP 5.1.x - 5.6.x

TYPO3 8.7: Supported by Ubuntu 16.04.
TYPO3 7.6: Supported by Ubuntu 12.04. & 14.04. & 16.04.
TYPO3 6.2: Supported by Ubuntu 12.04. & 14.04.

Reading these numbers I feel the need for TYPO3 9.x supporting Ubuntu 16.04 which runs PHP 7.0.x of of the box (the one year overlap would easen upgrade strategies imho).

*¹ See Ubuntu Server Team Meeting of 2017-01-18 (https://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-04-18-16.01.html) Quote: “At this week’s server team meeting they mentioned their plans for shipping PHP 7.1 in Ubuntu 17.10 and PHP 7.2 in Ubuntu 18.04 LTS. PHP 7.1 has been available but didn’t make it for Ubuntu 17.04 with PHP 7.0 being the default. PHP 7.2 should be available later in 2017 with a variety of changes.”

Regarding IE: IE in general has a very small market share. IE11 has a much larger market share than any Edge though ( 3.4% vs. 1.5%). And this is the last version on some Windows versions, so this statistic probably wont change much until 2018.

3 Likes

Hi all

Actual real world case from last friday: Big customer with a lot of money from the IT/pharma sector asks us for a new website. Marketing and sales wants TYPO3 as CMS. Company is ISO27001 certified and as such must do the CMS hosting inhouse. They work with CentOS. CentOS does not support PHP 7.0 today and third party repos are not allowed…

So, the customer will decide against TYPO3 just because of the fact that actual enterprise Linux distros do not support actual PHP versions.

And we are talking about PHP 7.1? Seriously?

Please, dear core devs, we really love your work! But you must understand that in the real world, the essential question is, if we can use TYPO3 at all or not. And if not, we all loose our customers. And you will loos your reason for existence…
The competition is large enough between agencies and different CMS, so please don’t let it fail on a too new PHP version!

Thank you for taking into account these facts.

Regards
Lukas.

8 Likes

Hello everyone,

I’d like to share my two point of views on this, on one side as a tech freak and on the other side as a technical manager of a small company with 300+ TYPO3 instances (and I think we can all relate to both to some extend).

TL;DR
PHP 7.1+ is a no go, MySQL 5.7 should not be a minimum requirement, IE 11 needs support.
See below for details and inputs.

PHP
As a tech freak, I’d say PHP 7.1 is a must because of the improvements it might bring (and just think of the additional performance!), but also as a tech freak I think that the core should be rebuilt as a ReactPHP-Servlet style standalone-inline-PHP Server able to run by calling php -S localhost:80, so there is a pretty biased point of view about performance and what TYPO3 (or any software by this standard) has to be about performance over everything. And from this point of view, PHP 7.1 or 7.2 makes total sense.
As a technical manager I see 300+ TYPO3 with still tons of legacy code that is already pretty hard to maintain, update, document and test in an 18 months lifecycle. Don’t get me wrong, I love the 18 months lifecycle because from a sales point of view, every 18 months you get a new product to sell to new customers that is up-to-date by the latest web standards and is fancy and stuff, but from where I stand, I’ll also have to maintain said sold product for at least five to ten years and if I have to include a server upgrade every 3 years in order to just be able to install the latest LTS of TYPO3, either my boss or my customer will get very angry at me because a.) either I’m doing work that isn’t paid or b.) I have to charge at least two extra days for an upgrade that brings him no noticeable added value.
Now, it is true that TYPO3 evolves thanks to the community (which I’d put in the tech freak group) that want’s to progress and use new technologies and have fun with new features and make everything pretty and shiney, but in the meantime, all money that goes into TYPO3 (I’m aware that most of the work done on TYPO3 is not paid for) comes from agencies and companies that need a stable product they can rely on and on the end of the day, these are also our customers and clients that allow us to put bread on the table.

Therefore: PHP 7.0

As for IE, I think really strongly about it, as all of you do, but again, big companies will still use it in 5 years so dropping the support is a no-go.

And about MySQL: I think everything has been said.

3 Likes

PHP

  • Keep PHP 7.0 support in v9: support more distros and possible to run at least v8 and v9 on same stack, all in with lolli here
  • Add PHP 7.2 support in v8 (and maybe even v7, if possible): we raised the supported PHP versions of 6.2 and v7 during their lifecycle, PHP will aim for maximum backwards compatibility, should be possible
  • On Windows we could suggest or even require (!?) to use PHP 7.1 (I see the benefit of the long file paths)

MySQL

  • Keep 5.5+ - support more distros and possible to run at least v8 and v9 on same stack
  • JSON support is nice, but no killer feature, could add support if DB allows but do not require it
  • Cool, if even lower MySQL versions are supported now by using Doctrine DBAL

IE

  • TYPO3 used for projects in counties and municipalities having a very slow upgrade cycle and MS centred end user stack && IE will be supported for years: do not drop it.

Just FYI about MySQL 5.7 - if we make it a minimum requirement we should go for 5.7.5, since there have been several breaking changes between 5.7.4 and 5.7.5

Especially this one https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_only_full_group_by will cause some headaches, since it changed the default setting which can now only be circumvented with the new ANY_VALUE() method, unless the user can override the server settings.

Nice. RHEL is pseudo-long-term in your opinion …
Note: the “E” stands for “Enterprise”. A grade we often claim for TYPO3 as well. :wink:
And concerning 3rd party repos: Stucki already said everything to be said about it.

But in the end, I have a very conservative (don’t know if this is a germanism, hope you will understand it correctly) opinion and strategy on production systems.
And this did not bite me ever, it is the opposite, it saved me already a couple of times in all these years since 2k3 …
But is absolutely ok for me if others want to push features earlier to production, I love those “beta-testers” for their effort and enthusiasm. :wink:

1 Like

So it says that “this topic will automatically close in 3 days”. Yet I haven’t heard any reason to raise the MySQL version requirement except that it would be nice to have…

Regarding PHP 7.0 vs. 7.1: No new reasons pro 7.1 as well. If anybody still thinks we can’t stay compatible with PHP 7.0, please share your reasons.

I’m happy to see more feedback from the sales department here. Please consider these valuable inputs!

1 Like

Hey Stucki,

this is an open discussion, as the discussion shows there seems no real reason IMHO to update the minimum requirements for v9 (at least in MySQL), but we will see the results in the voting phase (once the discussion is closed).

My personal preference after this discussion is clear:

  • Keep PHP 7.0
  • Set minimum MySQL version to 5.0 (instead of 5.5 as it is now)
  • Keep IE11 for now, as it it does not help much for us to drop support for IE11
2 Likes

@rtp-lru @moede @stucki @pbtypo3 @masterofd

All boils down to this right? But, if a new TYPO3 version does not bring noticeable added value, why would you want to upgrade?

And, if you insist on stable, long term support software, why would you want to run old unsupported software (PHP) on the one hand, but latest software (TYPO3) at the same time?

If you focus on enterprise and stability, just stay on 8ELTS, which support ends first quarter of 2022! At this point in time PHP 7.0 support expired for almost 2 years.

I would be thankful to get more insight in the reasoning what the benefits are for the TYPO3 project to support legacy platforms with a new TYPO3 release, while there are (older but still) supported TYPO3 versions at the same time, that support these platforms.

Thanks

Hi Benni!

I just wanted to make clear that if someone wants to raise the requirements (and votes like this) he should get into the discussion instead of just saying nothing (and still vote pro raise)…

After reading through all the feedback that was posted here, I support your suggestion: PHP 7.0, MySQL 5.0, IE11

2 Likes

The MySQL minimum requirements could stay by MySQL 5.5, I wouldn’t lower such things.

We may have extensions which won’t use DBAL but would stay with their hand crafted SQL statements.

As addition. Usage statistic from packagist: https://seld.be/notes/php-versions-stats-2017-1-edition