Minimum Requirements for TYPO3 v9

Minimum Requirements for TYPO3 version 9

As development starts for TYPO3 v9 we need to define the minimum requirements for PHP, MySQL and supported browsers.

Proposal

  • PHP: 7.1
  • MySQL: 5.7
  • Browsers: Drop support for IE lte 11 (but support Edge)

PHP 7.1

Pro

  • We can use nullable types (together with strict typing for more consistency)
  • EOL of PHP 7.0 is this year, TYPO3 9 LTS available fall next year
  • Finally fix long file paths in Windows problem (!)

Con

  • Distribution support may be limited
Distribution support
  • Ubuntu 18.04: yes
  • Debian 9: no (EOL probably 2020) - Through dotdeb / ppa available
  • SLES: no
  • RHEL: no (but: PHP 5.4.16 - so letā€™s forget about that fast)
  • Fedora: yes (next stable)

MySQL 5.7

Pro

  • Supports json types (doctrine does, too - as long as the dbms does [oracle, postgres, sqlserver && mysql > 5.6])
  • Doctrine support (either 5.0 or 5.7)

see http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#json

Con

Distribution support
  • Ubuntu: yes
  • SLES: yes (download from mysql directly)
  • RHEL: yes (download from mysql directly)
  • Fedora: yes

Drop IE support

Pro

  • use more native JS functionality
  • Reduce complexity / overhead

Con

  • last version of IE (supported until 2020 / 2025)

General Remarks

  • 7LTS / 8LTS will be around for quite some time being supported on all major linux distributions

Organizational

Topic Initiator: Susanne Moog
Topic Mentor: Benni Mack

2 Likes

My input on that:

PHP version

Keeping PHP 7.0:

  • Supporting more linux distros that have gone through the way of upgrading their servers for just TYPO3 v8
  • ā€œStableā€ => do not worry for now

Going with PHP 7.1 as minimum requirement:

  • Benefit: We can use nullable types
  • EOL of PHP 7.0 is end of this year, however TYPO3 9 LTS will be available in fall 2018.

Sidenotes:

  • Next Ubuntu 18.04 LTS will have PHP 7.1 at least shipped already, donā€™t know about the others.

MySQL

  • Right now weā€™re having MySQL 5.5+, 5.6 supports JSON types which might come in handy during v9 development maybe?
  • Donā€™t know about distro support out there. domainfactory only has 5.6 available AFAIK

Browser Support for Backend

  • Keeping IE11
    Still in use, but usage goes down, and in fall 2018 the situation might look different again (very possible)
  • Using Edge
    We should look what native JS we can then use and slowly migrate to plain vanilla JS or other JS frameworks
4 Likes

Generally speaking Iā€™m all for not raising the minimum supported version just because we can but if we really need to. Many Linux distros are not yet up to speed with current LTS requirements and need some (easy to do but still) manual care to allow that.

Iā€™d be for keeping PHP 7.0 for the time being, for sure thereā€™s many already cool features we could take advantage of, without absolutely requiring to jump again.

MySQL: having JSON support in 5.6 is for sure nice and we could possibly take advantage of it but remember that we switched to Doctrine DBAL? Meaning we should move onto a more agnostic way of thinking and JSON support may then be not available with the abstraction in place, meaning there is possibly no actual need to raise the requirement.

IE11 is not something general people will use and IE support in TYPO3 Backend is not that perfect when we compare with other browsers, but still, once you face bigger projects, you often need to somehow deal with such browsers and just telling the managers IE is not supported may be a point where you loose. If however you tell IE is supported but then show that actual editors have much more comfort with another widely used browser, then you make everyone happy and still do not need to worry (too much) about IE regarding compatibility.

7 Likes

The development of Typo3 is way to fast for our customers. They really like the qualities of Typo3, but there is no money for those fast LTS updates. The result is, that the Typo3 will stay on older versions if a new LTS version gives to much work to update. So I think for my customers it will be better to stay on PHP 7.

2 Likes

Using strict without nullable types causes gaps in the definition of return values and lets the work half done.

For this reason my vote goes for PHP 7.1 in the expectation it is supported by the providers with release of TYPO3 9 LTS.

PHP:
My personal opinion is that we should not provide support for something that is not supported by the manufacturer anymore. That means that PHP 7.0 is not maintained anymore, hence we should not officially support it. We could however avoid using PHP 7.1 only features, hence usage of PHP 7.0 is still possible, but to oneā€™s own risk.

MySQL:
I personally do not care about JSON (or any inline nested stored structure) of a relational DB at all. Hence our minimum can stay or we apply the same rule as above: only support, what is supported by the manufacturer.

Browser:
Making stuff working IEx is mostly annoying and needs quite some JS overhead we need to transfer to the client just for compatibility. (hint: native JS)
So Iā€™m all in for dropping this old stuff in the end of 2018.

1 Like

My concern is that TYPO3 doesnā€™t modernise fast enough to stay competitive.

I think it is acceptable if a customer just installs every second LTS. End of support of v7 is with release of v9.

1 Like

Are we forced to define and implement the final requirements for the 9 LTS now? Or can we go with PHP 7.0 until (e.g.) 9.4 and switch then to 7.1?
Because I see the point, that currently not all hosters are able or willing to provide PHP 7.1. But on the other hand staying with PHP 7.0 for the 9 LTS seems to be a no go to me. Because EOL of PHP 7.0 will be end of 2018, three month after the to be expected release date of the 9 LTS. So we would be forced to support the 9 for three years on an outdated PHP version.
So my vote would be:

TYPO3 v9.4 and below requires PHP 7.0
TYPO3 v.9.5 and later requires PHP 7.2 (no spelling mistake here)

2 Likes

Browsers

All modern browser are evergreen, meaning doing self-update to the latest version. This takes a lot of burden away.

I think we should not spend manpower in maintaining code for legacy browsers.

I am all in for raising dependencies, but we cannot affort to drop IE support completely. IE 11 is at least supported until end of 2020 with mainstream support and extended with support until 2025 since its coupled to the windows 10 lifecycle. This does not mean that all features also have to be available in IE11, but the system itself in general has to work.

3 Likes

My favourite discussion :slight_smile:
Like Xavier already said, I also think that requirements should only be raised if thereā€™s a need for it.

PHP

Debian Stretch will be released soon and it ships with 7.0. Disregarding of PHPā€™s EOL announcement, this means that 7.0 will continue to live on Debian until ~2020 (see https://wiki.debian.org/DebianReleases). The same may apply to other LTS distrosā€¦ Just keep that in mind when deciding for 7.1.
Of course itā€™s possible to use a newer (non-LTS) distro or install 3rd party packages, but that somehow contradicts with the main point of using LTS software.

MySQL

Assuming that PDO_MYSQL is used internally, I donā€™t even see why MySQL 5.5 is required right nowā€¦

Browser Support

I think the suggestion of Susi was not to drop support for IE11 but everything lower than (lte) IE11. Iā€™m neutral to this, just wanted to clarify. (EDIT: I was wrong, it means ā€œlower than or equalā€. Thanks @felix-althaus for pointing this out!)

5 Likes

lte IE11 definitely includes IE11. So Susiā€˜s suggestion was to drop IE11 supportā€¦

1 Like

PHP
7.0 as of Debian 9 Stretch (if they do not change to 7.1 before release but we are already in feature freeze)

MySQL
Isnā€™t it more depending on used DBAL version and support?

IE
Personally drop it, but customer wise we should support it in 9 LTS

(Wild guess for v10 would be PHP 7.2 and Edge gt 13 :wink: )

1 Like

Thanks for the feedback, indeed youā€™re right.

1 Like

Entirely agree with that, so voting for PHP 7.1.

As for MySQL, that should be dictated by Doctrine DBAL, so either MySQL 5.0 or MySQL 5.7. As it would be kind of awkward to go back in time with MySQL 5.0, and because Debian stretch default MySQL is actually MariaDB 10.1 (apparently the real MySQL is no longer available on stretch), I vote for MySQL 5.7.

1 Like

Can you tell me where we currently depend on MySQL 5.5? That makes no sense to meā€¦

1 Like

Srsly? Ubuntu?
Remember: TYPO3 is a ServerSide Application and only we developers ā€œuseā€ it locally (and then maybe also on ubuntu).
Professional (Linux-based) Webservers run on REHL, CentOS, Debian, maybe (but would not advice to) SLES ā€¦
(and pls, donā€™t get back with thereā€™s a ubuntu server edition ā€¦)

1 Like

Interesting how different perspectives can be, isnā€™t it :slight_smile:
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.

Benefits:

  • Finally implement semantic versioning
  • Expand the time a TYPO3 version can be used without breaking changes

Risks:

  • 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

6 Likes

@bastianbalthasarbux Either I miss the sarcasm or you are totally on the wrong track.

Professional webserver hosting means:

  • Security relevant fixes are applied in ā€œno timeā€.
  • The application stack keeps track with the surrounding environment.

That means the OS does not matter at all, as long as it gets patched.
What matters is how fast you keep track with your customerā€™s application. The application dictates the middleware.

So for webhosting I can only propose: Use whatever OS you like and use a proper repository for the middleware upwards.
Example: we use Ubuntu for live hosting, but we use everything else from third party repos (mariadb, php, apache).
Reason: Even if a bug in PHP is not security critical, it may have consequences to your application that might be security critical.

Regarding LTS and the ā€œtime issueā€. As noted above you have to live with your environment and that is the Internet and the PHP ā€œworldā€. So these dictate the pace. Currently I see major update cycles of middleware and application software of 6 to 18 months. Any middleware or OS software that can not keep track with this pace is simply not an option. full stop.

In the end what counts is what may happen in the worst case, because this is what the judge at court in the end will have to deal with. So as a hoster your main goal will mostly be to survive the worst possible customer you may have by providing an up to date system to your customer. Otherwise your customer may throw you ā€œinto jailā€ if something goes wrong on your side (hint: gross negligence).

1 Like

I mostly agree with Helmut on all said points, I see only one risk: Half-baked features, which are released and need to be fixed afterwards (which might be breaking again)

I donā€™t see the risk that people stick to LTS too long.
In conjunction to what I wrote above I see that many hosters start dropping the availability of non-supported (by PHP itself) PHP versions. Hence, forcing the customers to get their software up to date and compatible.
Since I do not expect a lot of breaking changes for the upcoming PHP version (heck, we have over-full-blown OOP in PHP now), most PHP code should stay compatible with newer PHP versions anyway.

So the pressure to update actually does not necessarily stem from the TYPO3ā€™s lifecycle, but is also very much influenced by the involved middleware.

And to repeat myself again: If a ā€œprofessionalā€ hoster is not able to provide an up to date PHP version a few weeks after its release, I would seriously question the ā€œprofessionalā€ attribute again.

1 Like