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.
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.
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.
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)
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.
My favourite discussion
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!)
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 ā¦)
Interesting how different perspectives can be, isnāt it
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
@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).
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.