Reconsidering PHP Minimum Requirements for TYPO3 v9

Discuss Topics
#1

Minimum PHP requirements - should they be PHP 7.0, 7.1 and 7.2

I want to rediscuss the topic of the minimum PHP requirements for TYPO3 v9:

Current Status on the PHP minimum requirements

  • We decided in May 2017 on PHP 7.0 as minimum requirement for TYPO3 v9
  • PHP 7.0 is in security-only mode will run out of security fixes in December 2018
  • PHP 7.2 was released last week, and security support will end in December 2020
  • We managed to get TYPO3 v7, TYPO3 v8 and TYPO3 v9 compatible with PHP 7.2

Just to get the TYPO3 dates off your tongues

TYPO3 v9 LTS will be released in October 2018, and supported by the community until October 2021 (= longer than the latest PHP 7.2 version officially).

Update on the distributions

So, here it is: By the time we ship TYPO3 v9 LTS, PHP 7.0 security support has two more months to go.

New issues due to our PHP dependencies

But the main reason for asking again is the heavy maintenance we’re gonna be under due to our composer dependencies:

Our main areas we heavily use dependencies on is Symfony and Doctrine DBAL. Both of their latest versions have a minimum requirement to PHP 7.1. However, Symfony 3.4 (LTS) has support until 2021, which works fine for our current workflow.

At this point, Doctrine DBAL switched to PHP 7.1 as minimum requirement, which is already stocks up a lot of support issues for us, as people use “composer” in a wrong way (they have to define their minimum version for their project). If we stick to PHP 7.0 for TYPO3 v9, this issue will follow us for the next 4 years (1y until LTS, and then 3ys of maintenance).

Additionally, we don’t know the Doctrine DBAL policy for security issues, if they ever get fixed in the “2.5” branch (with PHP 7.0 support) or only for newer versions, which would mean, we’d need to fork 2.5 to keep it running for us.

For me now it’s more an impact “should we stay in line with our dependencies and keep our version in sync” vs. “keep PHP 7.0 as minimal and deal with possible security issues ourselves then” rather than the syntactic sugar that comes with newer PHP versions.

In light of recent development (see above) I’d like to get your feedback again, basically what’s your preference:

  • PHP 7.0+
  • PHP 7.1+
  • PHP 7.2+

I will then consider your feedback and reconsider a voting again.

PS: For the time being I will raise the PHP minimum requirements for master now. If we decide on PHP 7.0 we can lower that barrier again for TYPO3 v9. Keeping “PHP 7.0” for TYPO3 v9.0, and then change it after a possible re-vote, would be a breaking change in a minor release. (of course we keep our dependencies as they are right now).

PPS: We will always try to keep TYPO3 versions as much “forward-compatible” with to-be-released PHP versions as possible, but promises can’t be made here of course.

Reference

Here you find the original discussion, you should really re-read it as most arguments are still valid IMHO:

Organizational

Topic Initiator: Benni Mack
Topic Mentor: Benni Mack

1 Like
#2

From a first look here and the discussions I’ve heard so far, I also support the move to PHP 7.1 as the requirement for 9 LTS.

I don’t see a point in having our central dependencies have a newer PHP requirement than us. This will create the additional maintenance burden for forks that Benni outlined, and I doubt that we can keep that level of support we would need for this (and this might create a host of compatibility problems).

2 Likes
#3

@benni Can you add info, about support dates for PHP 7.1?

I’m ok with raising the requirements to PHP 7.1.
I would prefer that the core team doesn’t have to maintain doctrine or other dependencies for the next few years.
If it comes to my customers, I see the trend that less and less customers sees RHEL with no external packages as a hard requirement.

#4

I repeat my not 100% serious statement from back then, when 7.2 wasn’t even a dirty thought and the successor could have been 8.0:
Let’s require PHP 8.0

Rephrasing this for the current state:
Let’s require 7.2

#5

I opt to raise the requirement to PHP 7.1, too.

At least for Ubuntu I know they release their next LTS in 2018-04, coming with PHP 7.1: https://launchpad.net/ubuntu/bionic/+source/php7.1

1 Like
#6

I will opt again for 7.1 for the same reasons :slight_smile:

1 Like
#7

Voting for 7.1 or even 7.2 support. There were many reasons in the old thread and I just want to go with the things Helmut already mentioned. If someone wants to host his NEW TYPO3 instance on an ancient debian system, he has the option to go with ELTS.

1 Like
#8

IMO 7.2 as a minimum version for the LTS version would make sense.

Not sure if we should already raise it. Is php 7.2 currently already available in for the main distributions/hosters?

Think that should be in line with our minimum required versions to have some adoption in the field of the 9.x versions

#9

What about raising the minimum version to 7.1 for now and discuss 7.2 (for the LTS version) next summer? I guess we have better numbers then about the acceptance of 7.2 in linux distributions and from hosters.

Short explanation:
Most people will only use the LTS version for years but not the sprint releases, so I think they are to be treated differently.

3 Likes
#10

Given the dependency-problem and having to maintain our PHP-version-promise for so long I agree we should go for at least 7.1. And I agree with Markus that even 7.2 for 9 LTS is not that far fetched.

@Alex: Benni said the goal would be to communicate a requirement upon release of 9.0 that we plan to keep throughout 9 LTS as well then. So raising it to 7.1 now and to 7.2 upon 7 LTS-release wouldn’t be an option then. Requiring 7.2 now and before 9 LTS-release lowering that barrier to 7.1 again would be okay of course.

I feel that whatever we decide today (7.1 or 7.2) will result in feedback from users “but I only have 7.0 today”. We’ll need to explain here and there anyway. So maybe communicating 7.2 now and see what the feedback will be might be an option. If the pressure is too high until 9 LTS-release we can still revert to 7.1 - but I have the feeling that by then even 7.2 might be “doable”.

And it’s not that we say it won’t run at all on 7.1 or 7.0. It’s “just” not officially supported. What we can do from our sides (not taking dependent packages into account) imho we’ll still try to support with 7.0 as well. We can still let our tests run against 7.0 for some more time and see what breaks - and see then when a “cool new feature” (7.2 only) is introduced in our codebase if we want to have that or could easily find a way to also keep it running on 7.0/7.1.

#11

Here is the overview of PHP-version-support: https://secure.php.net/supported-versions.php

#12

I think 7.2 should be the minimum version for LTS but as said by @alexanderschnitzler we have better numbers around summer. The only thing is that this should be communicated quite transparent if you would like to raise the minimum version of PHP during development of a major version. This could lead into some discussions because hosting agencies should be prepaired for this and some will need some time to fix this I think.

#13

I don’t have a strong opinion on that, but raising to 7.1 is fine for me; I tend to agree with @alexanderschnitzler about discussing support for 7.2 later

#14

To sum it up: Ubuntu 16.04, Debian 9 (Stretch) as well as SLES 12 all have no support for PHP 7.1 or later. It can be changed by adding 3rd party repos but there’s no official support.

Official support for PHP 7.1+ is only possible using Ubuntu 18.04 or RHEL / CentOS 7 (through an additional repo which is maintained by RedHat) and Docker (don’t forget!).

IMO you should be clear about this. If someone doesn’t want (or is not allowed) to use 3rd party repos, then he will either need to switch the OS or stick with TYPO3 8 LTS.

Another possibility (which is what we do at snowflakeOps) is to build our own PHP 7.0 for Debian Jessie using GitLab CI and our own package repository. The same can be repeated easily for PHP 7.2 and Debian Stretch…

With that in mind, I think that it makes sense to raise the requirement to 7.1. If only RedHat provides similar 7.2 repos until TYPO3 9 LTS is out, then I would even go for PHP 7.2…

1 Like
#15

raise to PHP 7.1+ now, discuss PHP 7.2+ before releasing v9 again

1 Like
#16

So, we’re torn between the OS support of PHP and the supported PHP versions of third party libraries we depend on.
Ubuntu 14.04 receives updates until the beginning of 2021 and will continue to ship PHP 7.0 which will receive backports of patches.
For TYPO3 6.2 the OS support was the argument to set the supported PHP versions. Back then we didn’t use composer and we could patch the libraries that were shipped if necessary.
With composer it has become easier to use external libraries without thinking too much about their support strategies.

The question here is more, where do we position our product and what will our support strategy be? Are we a CMS that will support the LTS OS environments that enterprises use? Are we a CMS that uses more modern technologies and will we accept that companies/organizations with a more conservative platform strategy can’t use us? Or do we take a different position?

The answer to that question will also have implications for which browser, OS, PHP, DBMS, etcetera we support and which third party libraries we can use. For these libraries we have to make sure that they will fit that support strategy or we have to realize that at some point we have to fork the library and do the support ourselves.

2 Likes
#17

I support going to raising to version 7.1.

#18

I vote to for for PHP 7.2+. I don’t see much difference in cons between 7.1 and 7.2, so we might as well go all the way.

#19

As others said here I opt for 7.1 as a first step and 7.2 could be another discussion in a couple of months when the numbers are there.

#20

I am with alexanderschnitzler and all the others: 7.1+ and look what happens till summer with 7.2 acceptance (breaking changes etc.)

I also want to exclaim what Jigal said: “With composer it has become easier to use external libraries without thinking too much about their support strategies.”

1 Like