search

gggeek / phpxmlrpc

A php library for building xmlrpc clients and servers
http://gggeek.github.io/phpxmlrpc/
Other
227 stars 94 forks source link

Bump php-version to 5.6 / 7 #52

Open HMAZonderland opened 7 years ago

HMAZonderland commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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

gggeek commented 5 years ago

@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 commented 5 years ago

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

gggeek commented 3 years ago

Small update:

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 commented 2 years ago

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 commented 2 years ago

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

joelfan commented 2 years ago

Ok, Thx a lot!

gggeek commented 1 year ago

Small update: as of today

glensc commented 1 year ago

You should use this action:

rather implementing the pipeline yourself:

gggeek commented 1 year ago

@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...