Hi Dominique De Vasconcelos,
The reasons are in short that we assumed the situation with Debian will solve itself before we reach the 2.x LTS version by end of 2018, and the need for long term packages becomes important for what we recommend.
For the longer version:
- This is the first Fast Track Release towards the 2.x LTS release by the end of the year, and given:
- Both Symfony 4, Doctrine, and several other packages we use are now starting to require PHP 7.1, we wanted to make sure we can open for use of Symfony 4 (in this case experimental until 2019) and newer Doctrine versions (for enhanced storage engine) and so on within the year instead of having to wait until next release cycle
- There are several language improvements we wanted to take advantage of, and also let community be able to take advantage of
- The assumption was that most hosting providers either already have php 7.1 support or is going to add it over the course of the year.
- In the case of Debian what we saw is that Debian 9 made sure to rename packages to php7.0 making space for having several versions in the future
- And in the case of Redhat/CentOS there is RHSCL packages
- Use of Docker, which we use ourselves both for testing & demoes, however given its complexity and rapid change we don't blindly recommend it (but as long as php versions are what we support it is techanlly supported, you "just" need to deal with docker and kubernetes/swarm problems yourself)
- Or our new eZ Platform Cloud, a recommended and specialized tuned setup which already supports PHP 7.1, and which allows you to focus on the code over the servers
Hope this helps clarify the reasoning, and if you think this is a wrong move don't hesitate to say so. Both Engineering, Product management and Customer Success (incl Support) is more then open to re-evaluate the choice if it turns out to be the wrong one.
VP Customer Success