Details

Description

Debian Stretch had just been released a few month ago and only supports PHP 7.0 with the official repositories. Which means that ezplatform 2.0 cannot be installed on this OS because of the php 7.1 requirement in the composer.json (please don't tell me to use remi repositories).

Ezplatform is based on Symfony 3.4, which is compatible with PHP 7.0. So why enforcing the PHP 7.1 version in the composer.json. Is ezplatform 2.0 really incompatible with the 7.0 version ?

Activity

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

Until that happens we of course support (not as a recommendation, but as supported option) use of thridparty packages such as https://deb.sury.org/(debian equivalent of ppa:ondrej/php)

And in the case of Redhat/CentOS there is RHSCL packages

Alternatives:

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.

André Rømcke
added a comment - 04/Jan/18 12:14 PM - edited 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
https://symfony.com/blog/symfony-4-a-new-way-to-develop-applications
http://fabien.potencier.org/symfony4-performance.html
https://github.com/doctrine/dbal/releases/tag/v2.6.0
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
So PHP 7.1 is already part of Debian Buster ("testing") , and with time it should in theory appear in stretch-backports
Until that happens we of course support (not as a recommendation, but as supported option) use of thridparty packages such as https://deb.sury.org/ (debian equivalent of ppa:ondrej/php)
And in the case of Redhat/CentOS there is RHSCL packages
Alternatives:
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.
Best regards,
André Rømcke
VP Customer Success

Thank you for this complete answer.
For Symfony 4, the LTS (4.4) will be released on 09/2019, so if you plan to release a new eZPlatform LTS by the end of the year will it shouldn't be based on a 4.x version but on 3.4. Am I wrong ?https://symfony.com/doc/current/contributing/community/releases.html
In my opinion, eZPlatform 2.0 should be compatible with both 7.0 and 7.1 PHP versions to be able to use a standard Debian (or other) distributions and to be able to migrate to 7.1 as soon as we can update our OS.
This could avoid a lot of discussions with the hosting team to know how the server must be installed (some hosting teams do not allow to use backport packages).

Dominique De Vasconcelos
added a comment - 15/Jan/18 5:27 PM Hi André,
Thank you for this complete answer.
For Symfony 4, the LTS (4.4) will be released on 09/2019, so if you plan to release a new eZPlatform LTS by the end of the year will it shouldn't be based on a 4.x version but on 3.4. Am I wrong ?
https://symfony.com/doc/current/contributing/community/releases.html
In my opinion, eZPlatform 2.0 should be compatible with both 7.0 and 7.1 PHP versions to be able to use a standard Debian (or other) distributions and to be able to migrate to 7.1 as soon as we can update our OS.
This could avoid a lot of discussions with the hosting team to know how the server must be installed (some hosting teams do not allow to use backport packages).
Regards,
Dominique