Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0
    • Fix Version/s: None
    • Component/s: Composer
    • Environment:

      Debian stretch

      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 ?

      Regards

        Issue Links

          Activity

          Dominique De Vasconcelos created issue -
          Hide
          André Rømcke added a comment - - 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:
          • 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
            • 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

          Show
          André Rømcke added a comment - - 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
          Hide
          André Rømcke added a comment -

          Reported issue to Debian as well (request for 7.1 backport to Stretch): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886722

          Show
          André Rømcke added a comment - Reported issue to Debian as well (request for 7.1 backport to Stretch): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886722
          André Rømcke made changes -
          Field Original Value New Value
          Remote Link This issue links to "Debian Bug report | php: Backport of buster PHP7.1 to stretch-backports (Web Link)" [ 17968 ]
          Hide
          Dominique De Vasconcelos added a comment -

          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

          Show
          Dominique De Vasconcelos added a comment - 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

            People

            • Assignee:
              Unassigned
              Reporter:
              Dominique De Vasconcelos
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: