New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP 5 / 7 compatibility #13831

Closed
nijel opened this Issue Nov 23, 2017 · 15 comments

Comments

Projects
None yet
4 participants
@nijel
Member

nijel commented Nov 23, 2017

As more and more PHP libraries are starting to be PHP 7 only, we should address this somehow to ensure our releases will not break for some users. This came up in #13826, but can affect other parts of our code as well. In this particular case one library is using PHP 7 features, what fails on PHP 5. This seems to be correctly expressed in deps in this case, but this doesn't have to be true.

Anyway on the release time, we bundle libraries into tarball. This should work for all supported versions, not only for the one building release. For example right now the snapshots are built using PHP 7, so at least 2FA will fail in them on PHP 5.

Few ways to address this:

  • Always run release creation with oldest PHP we support.

    This is probably achievable, however that means that we're relying on EOLed version to do the releases. That's probably not problem as it's used on command line only, but still feels strange.

    Same version should be used when @ibennetch is doing releases and on the server to build snapshots to have the releases and snapshots consistent.

  • Use composer configuration to enforce PHP 5.5 deps

    Composer can be used to override PHP version for deps using composer config platform.php 5.5. Having this in our composer.json would make all installations behave like having PHP 5.5. This can be configured just on the releasing system by composer config -g platform.php 5.5.

  • Define PHP 5 dependencies in composer.json.

    We need to keep eye on problematic libs so that composer always chooses older versions compatible with both PHP 5 and 7.

  • Drop PHP 5 support.

    Sounds unrealistic as even dropping support for PHP 5.5 was not yet agreed, see #13228. However that would allow us to use modern PHP features such as type hinting...

Note that all but last options apparently lead to using old and thus possibly insecure or unsupported libraries in our releases.

Do you see other options how to deal with this?

@nijel nijel added this to the 4.8.0 milestone Nov 23, 2017

@nijel

This comment has been minimized.

Member

nijel commented Nov 23, 2017

Currently there are just two libs differing between PHP 5.5 and 7.1, this is what happens when I upgrade from 5.5. to 7.1:

$ composer update --no-dev
Loading composer repositories with package information
Updating dependencies
Package operations: 5 installs, 2 updates, 0 removals
  - Installing symfony/polyfill-apcu (v1.6.0): Loading from cache
  - Installing psr/simple-cache (1.0.0): Loading from cache
  - Installing psr/log (1.0.2): Loading from cache
  - Installing psr/cache (1.0.1): Loading from cache
  - Installing symfony/cache (v3.3.13): Loading from cache
  - Updating symfony/expression-language (v2.8.31 => v3.3.13): Loading from cache
  - Updating paragonie/constant_time_encoding (v1.0.1 => v2.2.0): Loading from cache
Writing lock file
Generating autoload file
@nijel

This comment has been minimized.

Member

nijel commented Nov 23, 2017

For now I've configured the snapshots to use composer config -g platform.php 5.5, so that they will work on PHP 5.5. On the other side nobody complained so far, so probably nobody tried that so far :-).

@mauriciofauth

This comment has been minimized.

Member

mauriciofauth commented Nov 23, 2017

We can create the 5.0.0 milestone and open an issue, with this milestone, to set PHP 7.1 as a minimum requirement, dropping support for PHP 5, PHP 7.0 and HHVM. See gophp71.org.
We can also mark the latest version of the 4.x branch as a Long Term Support version. Because it will be the last version to support PHP 5.

@ibennetch

This comment has been minimized.

Member

ibennetch commented Nov 23, 2017

This comment is to add and consolidate information about the official support status of various PHP versions. Feel free to edit it as needed.

Official PHP:
5.5 is EOL and not supported
5.6 gets security support only until December 2018
7.0 active support ends in days (December 2017); security support through December 2018

Debian:
LTS support of Wheezy (PHP 5.4) until May 2018
Current "oldstable" Jessie (PHP 5.6) until June 2018, then LTS until 2020
All other versions (stable, unstable, and testing) are all on PHP 7.0

Redhat packages are difficult to determine without a support contract, but here's CentOS:
CentOS 6.9 (PHP 5.3) supported until November 2020
CentOS 7.4 (current version) includes PHP 5.4 and is supported until 2024

XAMPP:
Currently includes PHP 7.1

WAMP:
Currently includes PHP 5.6

@ibennetch

This comment has been minimized.

Member

ibennetch commented Nov 23, 2017

When we finally do make the switch, I agree about what @mauriciofauth has written with the path forward. If we end up doing active development of both 4.x and 5.x, perhaps the 5.x development should occur in its own branch until 4.x enters our LTS phase, at which point master can merge in the 5.x branch. Just an idea, I'm quite confident that @nijel or one of the rest of you has a good grasp of how to manage that already, anyway.

We'll have to determine when to drop general bugfix support and new features for the 4.x line, and from the PHP versions I've posted I'm not sure whether it's time for that yet.

@ibennetch

This comment has been minimized.

Member

ibennetch commented Nov 23, 2017

My current platform for building the release would use PHP 7, although I can force that to change to PHP5 quite easily.

@nijel

This comment has been minimized.

Member

nijel commented Nov 24, 2017

I think we can target phpMyAdmin 5.0 to require PHP 7.1. But indeed we will have to support PHP 5 compatible version for quite some time (similarly as we supported 4.0 series).

The question is whether to rename 4.8 to 5.0, or release 4.8 first and then 5.0. I can see benefits in both approaches. Releasing 4.8 with PHP 5 support will bring us to similar code base for both supported versions making future maintenance a bit easier. Releasing directly 5.0 will allow us to use PHP 7.1 features right now in master and this will probably lead to better code.

In the end I think this boils down to when do we want to release 4.8/5.0, what is probably something we should decide anyway soon regardless this issue.

@mauriciofauth

This comment has been minimized.

Member

mauriciofauth commented Nov 25, 2017

It's better to release 4.8 with PHP 5 support and only then start developing 5.0, since 4.8 already has a few months of development.

@nijel

This comment has been minimized.

Member

nijel commented Nov 27, 2017

I tend to agree, this will make future maintenance easier as there are quite big changes between 4.7 and current master.

@nijel

This comment has been minimized.

Member

nijel commented Nov 27, 2017

Okay, I've created the 5.0.0 milestone for this.

@OlafvdSpek

This comment has been minimized.

OlafvdSpek commented Nov 30, 2017

It's better to release 4.8 with PHP 5 support

5.5 or 5.6?

@mauriciofauth

This comment has been minimized.

Member

mauriciofauth commented Nov 30, 2017

@OlafvdSpek PHP 5.5.

@OlafvdSpek

This comment has been minimized.

OlafvdSpek commented Nov 30, 2017

Why?
PHP 5.5 is already unsupported
Dependencies might drop (security) support for 5.5
Major platforms aren't on 5.5 according to #13831 (comment)

@nijel

This comment has been minimized.

Member

nijel commented Nov 30, 2017

If not anything else, than this will make future maintenance easier for us - if we would drop support for 5.5 in 4.8, we would be probably asked to extend security support for 4.7. Given that there is no big problem in supporting PHP 5.5, we should support it in 4.8. In 5.0, we can drop support for anything older than 7.1 and support 4.8 branch for users who had to stay on older PHP versions.

@mauriciofauth

This comment has been minimized.

Member

mauriciofauth commented Nov 30, 2017

It doesn't make much difference to require 5.5 or 5.6. So it's better to keep the 5.5 support. See #13228 comment and #13242 comments.

maniackcrudelis added a commit to YunoHost-Apps/phpmyadmin_ynh that referenced this issue Jan 5, 2018

@nijel nijel self-assigned this Jan 8, 2018

@nijel nijel closed this in 009246e Jan 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment