On Thu, October 22, 2015 11:20 am, Juan Bernhard wrote: > > El 22/10/2015 a las 12:48 p.m., Valeri Galtsev escribió: >> On Thu, October 22, 2015 10:40 am, Jim Perrin wrote: >>> On 10/22/2015 10:31 AM, Andrew Holway wrote: >>>> Hi, >>>> So, it seems that the current version of PHP in Centos 7 is PHP 5.4.16 >>>> however this version of PHP stopped getting security support from the PHP >>>> people one month ago [1]. >>>> Now, our developers want to use the new and shiny PHP because they want >>>> to >>>> use the latest version of Zend. They are proposing using this package [2] >>>> but I never heard of this repo. >> For me it sound like an example of the difference between "bleeding edge" >> and "enterprise" systems. The first is what developers most often like, the second is what humble sysadmins prefer as they have to keep something >> developed long ago running for as long as possible - and without crashed, >> daemons dying etc (== "bleeding" which always accompanies "bleeding edge" >> anything). Sorry for venting my own usual pain here... >> Valeri > > PHP 5.4 is in EOL, it get no more security updates from PHP > developers... its may be a security risk to use this in in long term. centos should change the php version more ofthen. I dont uderstand centos 6, its still using php 5.3, who got EOL a year ago... I had to switch to another repo to get this (to not get the headache by compile by hand). > If you want to change to a log term support, you should use php 5.6, this is under active development now. > centos packagers mantainers should listen the PHP developers in this topic, they are the ones who really knows PHP > http://php.net/supported-versions.php > This yet once more exemplifies the point I was trying to make. If I build new system (with new components of end point software using, say PHP), then I would pick the latest stable version of PHP. Exactly as you are point out. And I prefer to roll new box out with all latest stable everything. From this point on, once I have the box in production, I often have no luxury (when time goes by) to upgrade some components other stuff needs to run with. Like PHP that will be latest stable 3 years down the road will be several minor versions up, and some of my end components may not run with it as some internals may have changed. At this point it is exactly what I am trying to stress: either I break things that I have no newer version that works with latest version of PHP, or I can stay with older version of PHP - if at all possible. This is basically the difference between, say, Debian (and clones) style of updates/upgrades (when update bring you new version of package) and RH Enterprise Linux which keeps older version (thus preserving all internals), and [doing tremendous job of] backporting security and bug fixes implemented in new version to older version. At least this is what we loved about RHEL - not quite sure to what extent it still is true recently. The best example of really troublesome compatibility would be python and modules for it. To my python developers and users I call python a "sneaky snake". Whoever worked with python and modules written for it knows what I talk about: you always beed to match versions of modules rather rigorously the version of python itself, or things will not work. There is, however excellent "Enterprise" piece of software written in python: mailman. I really never had any trouble of any kind with mailman. This is what I figure Mark meant when he said you can write software which will work with big range of different versions of whatever it depends on - he is (was?) developer, he knows what he is talking about. Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++