Bump php-version to 5.6 / 7

[HMAZonderland]

Php has also dropped support for php 5.3 / 5.4 / 5.5, also other mayor php-libraries have or are dropping support for anything php 5. It is also preventing your library from moving forward as dependencies you use are only supporting php 7+. For instance you cannot run phpunit (6) in php 7 through Travis at this point.

It would also give you the ability to drop all the old legacy code and go really bananas.

[gggeek]

Mostly agree.
However, Debian Wheezy, still supported in LTS phase, does ship with php 5.4.
(RHEL/Centos do have an even older default version of php in one currently supported platform, but they have at least php 5.6 available in the Software Collections repos)
And phpxmlrpc has always been much keener on backwards compatibility than new features.
In other words: I am not sure I will do the in the next minor version...

[HMAZonderland]

If we have a look at other libraries such as Doctrine and Symfony they have moved the PHP-community forward by dropping support on older (non-maintained or supported) php-versions. I do not think we should let an operating system dictate your support schedule.

Older PHP versions are vulnerable we see a lot hacks happening on servers which run older php-versions because they do not upgrade. If any maintainer would bump their support to php 5.6 or 7 (which would be best) and drop support for older versions server maintainers have to upgrade which makes the world a safer place.

The php-community has been stuck to long in php 5.*, lets move forward!

[glensc]

aligning with phpunit is very wrong (what's the right word here?). each project may have their own support cycle. and phpunit development moves way to fast to catch that train.

this library can be made support php 7 and php 5 same time. you don't have to kill php 5 compatibility just to to support php 7.

currently composer allows exactly that: https://github.com/gggeek/phpxmlrpc/blob/4.3.1/composer.json#L8

[gggeek]

2 years later... I was actually thinking about dropping support for at least 5.3, and possibly 5.4 and 5.5 as well.
a) Travis makes it hard to test on those php versions
b) even the for versions of php bundled with LTS linux releases the oldest one available by now is 5.6 (to be confirmed)

[glensc]

Travis is pretty easy, you need dist: precise for 5.3:

• https://github.com/eventum/rpc/blob/v4.3.0/.travis.yml#L9-L17

you may need to install phpunit from composer, the included version in travis image is usually wrong or outdated:

• https://github.com/eventum/rpc/blob/v4.3.0/.travis.yml#L29

[gggeek]

@glensc thanks for the tip! I was under the impression that Precise images had been deprecated by Travis.org, but reading the blog posts now I can't seem to find that info any more...

There it is! https://travis-ci.org/gggeek/phpxmlrpc/jobs/534116347 => " This job ran on our Precise environment, which is in the process of being decommissioned.".

I could try to use Trusty as base for tests running on 5.3 => 5.6, but I am not sure if it's worth it if it includes keeping up to date 2 sets of configurations for Apache (I had to change it going from Precise to Xenial...)

[glensc]

Well, that decommissioned note is there for a very long time, until not decommissioned, can be still used ;)

[gggeek]

Small update:

• as of today, the lib passes its tests on php versions 5.6 .. 8.0 - this involved updating the versions of phpunit used (besides fixing a few bugs)
• I am not yet officially dropping support for php 5.3, even though atm travis tests still are not set up for 5.3 - in fact running tests on 5.3 just got more complicated due to usage of 'newer' phpunit
• I am in the process of adding to the test code a full test env based on Docker, to make it easier to run test locally on whatever php version is required

All in all, I don't think that I will drop support for php 5 until the new major version of phpxmlrpc (which will either come with a completely revamped API and codebase or not materialize at all ;-) )

[joelfan]

Hi gggeek.

I found an incompatibility with Php 8. I get problems with each use, which I believe is deprecated in Php7 and withdrown from Php8. Can you confirm this? Is there any plan to substitute the use of each?

[gggeek]

@joelfan I think you are using an outdated version of the library. current versions already removed an usage of the each function

[joelfan]

Ok, Thx a lot!

[gggeek]

Small update: as of today

• the minimum supported php version has been bumped to 5.4
• the automated tests are run on GitHub Actions, Travis being basically unuseable for open source
• the automated tests are run on all php versions from 5.4 to 8.2

[glensc]

You should use this action:

• https://github.com/marketplace/actions/setup-php-action

rather implementing the pipeline yourself:

• https://github.com/gggeek/phpxmlrpc/blob/02b7f45d24e026dd832abe0bea37621b7bee953a/.github/workflows/ci.yaml

[gggeek]

@glensc thanks for the suggestion, but atm I prefer sticking to home-built shell scripts for most of the gh actions workflow steps (both here and in other projects).

The main advantages are:

1. I can run the same workflows/test-suites locally using containers, and be confident that the environment is similar enough
2. I am ready to transition away from github without big pains, in case anything goes wrong with it. As unlikely as that might look, I was bitten once already by Travis when they started charging money for any non-trivial usage by open-source projects

I am aware of nektos/act as possible alternative solution for point 1, but so far I have heard mixed opinions about it, and have not had time to experiment with it. Also, it would do nothing for point 2, and actually increase the dependency on the gh ecosystem...