Page 1 of 1

PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Fri Aug 07, 2015 12:24 pm
by Imaging
FYI, PHP 5.4.44, 5.5.28 and PHP 5.6.12 are out:

http://php.net/archive/2015.php#id2015-08-06-4

with security fixes (in regards to updating the atomic repo and related packages).

Thanks.

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Tue Aug 11, 2015 12:12 pm
by scott
Updates are now out!

FYI I believe 5.4 is nearing EOL

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Tue Aug 11, 2015 2:06 pm
by Imaging
Thanks!

Yes, for 5.4, they do note:

__

Please note that PHP 5.4 branch is nearing the end of its support timeframe. Either September or October release, depending on discovered issues, will be the last official release of PHP 5.4. If your PHP installations is based on PHP 5.4, it may be a good time to start making the plans for the upgrade.

__

Will the base Atomic packages be transitioning to 5.5 or to 5.6 once 5.4 is EOL?

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Wed Aug 12, 2015 6:44 pm
by scott
Now is a good time for that discussion, at the very least its going to 5.5 and we'll continue to maintain 5.4 as a Nucleus package.

Going to 5.6 would probably be as disruptive as going to 5.5 honestly.

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Thu Aug 13, 2015 2:08 pm
by Imaging
Our developers would definitely prefer 5.6.

Given that the probable disruption is about the same as 5.5, we'd strongly vote for 5.6 as the new default.

Thanks.

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Fri Aug 14, 2015 4:21 am
by prupert
I vote for removing PHP out of the Atomic repository. For one, I am not using it anymore for a long while, because I believe there are too many QA issues (see repeating tickets re. missing or wrong dependencies) and the update latency is too high, sometimes weeks.

IMHO there are better repos for (all!) PHP versions available. And stick with EL7 stock if you do not require PHP > 5.4.

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Fri Aug 14, 2015 8:37 am
by Highland
5.4 is slated to EOL on Sept 14, 2015. PHP 7.0 is slated to go GA in early Nov

http://php.net/supported-versions.php

If you need your PHP libraries built faster, Remi runs a repo that generally builds the same day as any given release (Remi is a contributor to the PHP project so he tends to build based on tagging). Each version of PHP gets its own repo so you're always installing php RPMs and not something hacky like php56

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Fri Aug 14, 2015 10:29 am
by prupert
Highland wrote:<Abour Remi> Each version of PHP gets its own repo so you're always installing php RPMs and not something hacky like php56
Remi actually provides both methods: overwriting base php packages, or SCL-like additional php55/php56 packages. And, using different package names when overwriting EL stock packages is actually not that hacky, it has a very special purpose. See http://wiki.centos.org/AdditionalResour ... tories/SCL and https://iuscommunity.org/pages/TheSafeR ... ative.html.

See also warnings about Remi, and in particular about Atomic, under "Known Problem Repositories" on http://wiki.centos.org/AdditionalResources/Repositories.

While the default Remi repositories conflict/override EL stock PHP packages, the repo is disabled by default (yay!) and also provides a "safe repo" with packages not conflicting with or overriding EL stock PHP packages, see http://blog.remirepo.net/post/2015/06/0 ... y-for-EL-7. I am actually quite satisfied with how Remi is managing his repositories lately, but you should still be careful using such one-man-show unofficial repositories.

Re: PHP 5.4.44, 5.5.28 and PHP 5.6.12

Posted: Fri Aug 14, 2015 7:32 pm
by scott
What we might do is shift PHP entirely to SCL packaging. This particular SCL project has become the most popular project in the archive by far, we had a single client install it on 10,000 docker instances of the course of a few days.

Now that platforms like plesk and soon cpanel have adopted the SCL approach here the collateral is starting to build up in terms of documentation & KB's that the SCL idea isnt so alien to everyone in the CP business.

I wouldn't have proposed this even a year ago, but with the technology shifting away from traditional hosting/control panels and more into environments like docker it seems like this is going to be the new normal.