Looking forward next year and PHP versions
Hi, Unlike the MySQL version, I am not sure at all but here are some thoughts. First, how is the world regarding PHP versions? *) By 2007, Debian Etch with PHP5 support will be out. (It's currently scheduled to December 2006 and even if it slips to Jan 2007, it matters little here). Please do not litter the thread with praise/critique/flames re. Debian. *) 2007 will see PHP 6.0 released (http://www.infoworld.com/article/06/10/31/HNphproadmap_1.html) and I think this means PHP 4 will be EOL'd. Of the PHP5 line, I would consider only PHP5.1, as 5.0 is pretty old and broken in very interesting ways. Also note that 5.2 is already out. And what Drupal could do? *) Drupal 6 could have PHP 4.4 as a minimum so that we can use Unicode properties in pregs and thus simplify search module for example. *) Drupal 6 could begin to deprecate PHP4 with using PHP5 only functions , like array_diff_key , array_walk_recursive and such. These could be emulated by an include file. We would not use features that can't be emulated. With this technique we can have quicker and smaller code on PHP5 and still keep compatible with PHP4. We might need to talk to the guys who have written PEAR PHP Compat -- what they think of GPL'ing a part of that work? The problem is that some functions can be --easily-- emulated only in one way and I do not want to appear as if we stolen their code. *) Drupal 7 could drop PHP4 compat alltogether. If we keep the six month schedule, this will be released around the end of 2007 and run in 2008, so I think it's time. Unless we begin to use some advanced OOP mojo of PHP5 it's very likely that with the compatibility include and some PECL extensions D7 would still run on PHP4 -- just it would not be supported. I had some list here of what I want to use in PHP5 but I simply do not want this thread to divulge into that. Let's pretend we have an agreement that we know there are stuff exclusivel to PHP5 which we want. So, what do you think of climbing the version ladder? Please, please try to be on topic, this will be hard enough without another lamer commenting "oh great, but when Drupal 5 will be out". Regards NK
On Tue, 2006-11-14 at 16:54 +0100, Karoly Negyesi wrote:
Hi,
Unlike the MySQL version, I am not sure at all but here are some thoughts.
First, how is the world regarding PHP versions?
*) By 2007, Debian Etch with PHP5 support will be out. (It's currently scheduled to December 2006 and even if it slips to Jan 2007, it matters little here). Please do not litter the thread with praise/critique/flames re. Debian.
*) 2007 will see PHP 6.0 released (http://www.infoworld.com/article/06/10/31/HNphproadmap_1.html) and I think this means PHP 4 will be EOL'd. Of the PHP5 line, I would consider only PHP5.1, as 5.0 is pretty old and broken in very interesting ways. Also note that 5.2 is already out.
And what Drupal could do?
*) Drupal 6 could have PHP 4.4 as a minimum so that we can use Unicode properties in pregs and thus simplify search module for example.
*) Drupal 6 could begin to deprecate PHP4 with using PHP5 only functions , like array_diff_key , array_walk_recursive and such. These could be emulated by an include file. We would not use features that can't be emulated. With this technique we can have quicker and smaller code on PHP5 and still keep compatible with PHP4. We might need to talk to the guys who have written PEAR PHP Compat -- what they think of GPL'ing a part of that work? The problem is that some functions can be --easily-- emulated only in one way and I do not want to appear as if we stolen their code.
*) Drupal 7 could drop PHP4 compat alltogether. If we keep the six month schedule, this will be released around the end of 2007 and run in 2008, so I think it's time. Unless we begin to use some advanced OOP mojo of PHP5 it's very likely that with the compatibility include and some PECL extensions D7 would still run on PHP4 -- just it would not be supported. I had some list here of what I want to use in PHP5 but I simply do not want this thread to divulge into that. Let's pretend we have an agreement that we know there are stuff exclusivel to PHP5 which we want.
So, what do you think of climbing the version ladder? Please, please try to be on topic, this will be hard enough without another lamer commenting "oh great, but when Drupal 5 will be out".
Regards
NK
I'm for the move. Most of my servers are running php5.x / mysql5.x already, with the rest scheduled for migration before the end of the year. I like seeing the older versions of php dropped. There is better XML support in php5. I really would love to forget that expat exists at all. SimpleXML makes it easier to consume and implement quite a few web services. is anyone aware of the support roadmaps in the RedHat camps?
At 12:48 PM -0500 14/11/06, Darrel O'Pry wrote:
is anyone aware of the support roadmaps in the RedHat camps?
RHEL4 and CentOS4 are PHP 4.3.9 and MySQL 4.1.20. They will be supported with security updates until 2012. RHEL5 will have PHP 5.1 but still MySQL 4.1. The upgrade from RHEL4 to RHEL5 should be fairly painless for most users. ...R.
is anyone aware of the support roadmaps in the RedHat camps?
Yes, this is in the upcoming RHEL5: "Perhaps more importantly to many RHEL shops, version 5 of PHP is also slated to finally to be included for the first time in an official distribution of RHEL from Red Hat. " beta 1 is out, "Final release is expected early 2007" Chimes with our schedule. (from a cursory look, the free clones already include PHP5)
Hi, Karoly Negyesi wrote:
Hi,
Unlike the MySQL version, I am not sure at all but here are some thoughts.
First, how is the world regarding PHP versions?
*) By 2007, Debian Etch with PHP5 support will be out. (It's currently scheduled to December 2006 and even if it slips to Jan 2007, it matters little here). Please do not litter the thread with praise/critique/flames re. Debian.
This is just great. I have using the experimental versions of this for ages. And I think that this is what is in Ubuntu Linux. For me Debian/Ubuntu with PHP5 is so easy to set up a site. I think the only thing that is missing from Debian for a PHP set up is an opcache. I usually need to compile APC from PECL. I would love to use eAccelerator. But it doesn't really like PHP5 objects very much. I know that it crashes on CiviCRM.
*) 2007 will see PHP 6.0 released (http://www.infoworld.com/article/06/10/31/HNphproadmap_1.html) and I think this means PHP 4 will be EOL'd. Of the PHP5 line, I would consider only PHP5.1, as 5.0 is pretty old and broken in very interesting ways. Also note that 5.2 is already out.
This will be great to see. For all of my development I use PHP5.
And what Drupal could do?
*) Drupal 6 could have PHP 4.4 as a minimum so that we can use Unicode properties in pregs and thus simplify search module for example.
*) Drupal 6 could begin to deprecate PHP4 with using PHP5 only functions , like array_diff_key , array_walk_recursive and such. These could be emulated by an include file. We would not use features that can't be emulated. With this technique we can have quicker and smaller code on PHP5 and still keep compatible with PHP4. We might need to talk to the guys who have written PEAR PHP Compat -- what they think of GPL'ing a part of that work? The problem is that some functions can be --easily-- emulated only in one way and I do not want to appear as if we stolen their code.
*) Drupal 7 could drop PHP4 compat alltogether. If we keep the six month schedule, this will be released around the end of 2007 and run in 2008, so I think it's time. Unless we begin to use some advanced OOP mojo of PHP5 it's very likely that with the compatibility include and some PECL extensions D7 would still run on PHP4 -- just it would not be supported. I had some list here of what I want to use in PHP5 but I simply do not want this thread to divulge into that. Let's pretend we have an agreement that we know there are stuff exclusivel to PHP5 which we want.
So, what do you think of climbing the version ladder? Please, please try to be on topic, this will be hard enough without another lamer commenting "oh great, but when Drupal 5 will be out".
I think that this would be a good idea. Being able to use the latest and greatest versions of PHP will mean that we can start to use the new and better functions and improve how we do things. Gordon.
Regards
NK
!DSPAM:1000,4559ede961601670870668!
*) By 2007, Debian Etch with PHP5 support will be out. (It's currently scheduled to December 2006 and even if it slips to Jan 2007, it matters little here). Please do not litter the thread with praise/critique/flames re. Debian.
This is just great. I have using the experimental versions of this for ages. And I think that this is what is in Ubuntu Linux.
For me Debian/Ubuntu with PHP5 is so easy to set up a site. I think the only thing that is missing from Debian for a PHP set up is an opcache. I usually need to compile APC from PECL.
For those interested, here are details on how to install APC for PHP on Ubuntu/Debian. http://baheyeldin.com/technology/linux/installing-php-apc-on-ubuntu-dapper-a...
So, what do you think of climbing the version ladder? Please, please try to be on topic, this will be hard enough without another lamer commenting "oh great, but when Drupal 5 will be out".
Karoly, You are really tempting this lamer ... ;-)
On Tuesday 14 November 2006 09:54, Karoly Negyesi wrote:
And what Drupal could do?
*) Drupal 6 could have PHP 4.4 as a minimum so that we can use Unicode properties in pregs and thus simplify search module for example.
I don't think this is unreasonable. While I appreciate shared hosts' concerns re backward compatibility, security patches are only happening on 4.4.x now for the PHP 4 branch. 4.3 is effectively unsupported by default. (I'm personally rather surprised that Drupal doesn't already require 4.3.9 or 4.3.10 anyway, since those were stable and widely deployed for a long time.)
*) Drupal 6 could begin to deprecate PHP4 with using PHP5 only functions , like array_diff_key , array_walk_recursive and such. These could be emulated by an include file. We would not use features that can't be emulated. With this technique we can have quicker and smaller code on PHP5 and still keep compatible with PHP4. We might need to talk to the guys who have written PEAR PHP Compat -- what they think of GPL'ing a part of that work? The problem is that some functions can be --easily-- emulated only in one way and I do not want to appear as if we stolen their code.
I would support this as well. I already use array_combine(), scandir(), and similar PHP 5- only functions in my own work (either with PHP_Compat or with my own less-good versions), and find them invaluable. Even just adding in compatibility functions for such things without dropping support for anything officially would be good.
*) Drupal 7 could drop PHP4 compat alltogether. If we keep the six month schedule, this will be released around the end of 2007 and run in 2008, so I think it's time. Unless we begin to use some advanced OOP mojo of PHP5 it's very likely that with the compatibility include and some PECL extensions D7 would still run on PHP4 -- just it would not be supported. I had some list here of what I want to use in PHP5 but I simply do not want this thread to divulge into that. Let's pretend we have an agreement that we know there are stuff exclusivel to PHP5 which we want.
My concern here is the number of shared hosts that are still PHP 4 only. I don't know what that market will look like in a year, but I recall hearing that the PHP.net folks are planning to maintain three versions of PHP in parallel. (I think they're insane, but that's just me. <g>) I'd love to be able to reliably leave PHP 4 in the past; I just don't know if the current market would let us get away with it. Didn't someone (Dries?) do a benchmark at some point that showed Drupal was faster under PHP 4 than PHP 5, by a slim margin? (I won't pretend to understand the internals of the Zend Engine well enough to explain why that would be.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 11/14/06, Larry Garfield <larry@garfieldtech.com> wrote:
I don't think this is unreasonable. While I appreciate shared hosts' concerns re backward compatibility, security patches are only happening on 4.4.x now for the PHP 4 branch. 4.3 is effectively unsupported by default. (I'm personally rather surprised that Drupal doesn't already require 4.3.9 or 4.3.10 anyway, since those were stable and widely deployed for a long time.)
It's more than shared hosts - RHEL4 uses 4.3.9. It still gets security updates through the RH backports system and will continue to for years to come. EOL Schedule: Red Hat Enterprise Linux (version 4): General Availability: Feb 15, 2005 Full Support (including hardware updates): Feb 15, 2005 -- Aug 31, 2007 Deployment Support: Sep 1, 2007 -- Feb 29, 2008 Maintenance Support: Mar 1, 2008 -- Feb 29, 2012 From: http://www.redhat.com/security/updates/errata/ Hosts can upgrade to a newer version, but I think it's incorrect to classify use of PHP4.3 as a "budget host" situation. It's also an "enterprise" situation. As has been said, I think it is reasonable to look forward to dropping PHP4.3 at the point where we see it's actual use falling. Since I have and support several sites on PHP4.3.9 with no intention to upgrade my PHP until RH does, I have a strong interest in representing the 40% of PHP users who are in my same boat and seeing compatibility for at least a while longer. Regards, Greg
EOL Schedule:
Red Hat Enterprise Linux (version 4): General Availability: Feb 15, 2005 Full Support (including hardware updates): Feb 15, 2005 -- Aug 31, 2007 Deployment Support: Sep 1, 2007 -- Feb 29, 2008 Maintenance Support: Mar 1, 2008 -- Feb 29, 2012
I hope we do not need to support PHP4 until 2012. I hoped for SimpleXML and SQLite but oh well. Still, I will use PHP5 array functions in Drupal6 and use parts PHP_Compat to keep compatible with PHP4. The speed penalty of this solution is just a function call instead of inlining. Regards NK
On Wednesday 15 November 2006 08:31, Greg Knaddison - GVS wrote:
On 11/14/06, Larry Garfield <larry@garfieldtech.com> wrote:
I don't think this is unreasonable. While I appreciate shared hosts' concerns re backward compatibility, security patches are only happening on 4.4.x now for the PHP 4 branch. 4.3 is effectively unsupported by default. (I'm personally rather surprised that Drupal doesn't already require 4.3.9 or 4.3.10 anyway, since those were stable and widely deployed for a long time.)
It's more than shared hosts - RHEL4 uses 4.3.9. It still gets security updates through the RH backports system and will continue to for years to come.
Yes, but is that real 4.3.9 or is that "Red Hat's bastardized 4.3.9"? I've learned over the years to simply not trust Red Hat's version numbering to be in any way related to the official package version numbering, as they like to backport things without changing a version number. And no, I really don't think we should keep PHP 4 support until 2012. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 11/15/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Wednesday 15 November 2006 08:31, Greg Knaddison - GVS wrote:
It's more than shared hosts - RHEL4 uses 4.3.9. It still gets security updates through the RH backports system and will continue to for years to come.
Yes, but is that real 4.3.9 or is that "Red Hat's bastardized 4.3.9"? I've learned over the years to simply not trust Red Hat's version numbering to be in any way related to the official package version numbering, as they like to backport things without changing a version number.
And no, I really don't think we should keep PHP 4 support until 2012. :-)
It's the bastardized one, but they only backport security stuff not features so it's not really confusing as to what it is. It's 4.3.9 features plus updated security. http://www.redhat.com/advice/speaks_backport.html And I agree, sometime between now and 2012 most people will move off of php4.3 and somewhere in there, great, we drop it. Regards, Greg
On 14 Nov 2006, at 16:54, Karoly Negyesi wrote:
Unlike the MySQL version, I am not sure at all but here are some thoughts.
This sounds like a reasonable plan, but I think we need to re- evaluate each of these decisions at the relevant time. The only decision we can make at this point, is whether to drop PHP 4.3 for Drupal 6. As you can see on [1], 40% of the users are still on PHP 4.3. Based on that data, I'd propose not to drop PHP 4.3 at this point. Would the facts change during the Drupal 6 development cycle, we can still decide to drop PHP 4.3 support. If you look at the trendlines in these graphs, it is clear that it could take up to 16 months for PHP 4.3 to phase out. Either way, it is dangerous to make predictions about how these things evolve, so I suggest we monitor them in real time and act accordingly. [1] http://www.nexen.net/chiffres_cles/phpversion/ evolution_de_php_sur_internet_octobre_2006.php -- Dries Buytaert :: http://www.buytaert.net/
On Wednesday 15 November 2006 01:37, Dries Buytaert wrote:
The only decision we can make at this point, is whether to drop PHP 4.3 for Drupal 6. As you can see on [1], 40% of the users are still on PHP 4.3. Based on that data, I'd propose not to drop PHP 4.3 at this point. Would the facts change during the Drupal 6 development cycle, we can still decide to drop PHP 4.3 support.
Yeesh. I didn't realize how far behind hosts were in that regard. Any idea if it would be safe to require a later PHP 4.3.x (.9 or .10)? I would also note that does not preclude a safe-backport of selected PHP 5 functions a la PHP_Compat, as chx suggested. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Yeesh. I didn't realize how far behind hosts were in that regard. Any idea if it would be safe to require a later PHP 4.3.x (.9 or .10)?
I do not see what that buys us. PHP 4.4 has a newer PCRE, that's good.
I would also note that does not preclude a safe-backport of selected PHP 5 functions a la PHP_Compat, as chx suggested.
As you can from my forwarded chat, parts of PHP_Compat now can be included in Drupal -- and very likely they will be. Regards NK
Am Mittwoch, den 15.11.2006, 02:07 -0600 schrieb Larry Garfield:
On Wednesday 15 November 2006 01:37, Dries Buytaert wrote:
The only decision we can make at this point, is whether to drop PHP 4.3 for Drupal 6. As you can see on [1], 40% of the users are still on PHP 4.3. Based on that data, I'd propose not to drop PHP 4.3 at this point. Would the facts change during the Drupal 6 development cycle, we can still decide to drop PHP 4.3 support.
Yeesh. I didn't realize how far behind hosts were in that regard. Any idea if it would be safe to require a later PHP 4.3.x (.9 or .10)?
I would also like to see php5 as requirement asap. (simpleXML and so on..) I don't think that php will keep security support for php4 up when php6 is out. So then, most folks will upgrade their php except some enterprise distries as the already mentioned RHEL. But.. as they have to stay with the old php version they would also have to stay with the "old" drupal version, which provides php4 compability. So if we want to support these enterprise distributions, I think we should decide to provide security support for a release, e.g. 5.0 for a longer time and don't impede development. regards, fago
is there a simplexml backport ? in PHP_Compat ?
How there could be? The necessary language elements are not there. See for example http://www.ister.org/code/simplexml44/doc.xhtml
On 11/16/06, Karoly Negyesi <karoly@negyesi.net> wrote:
is there a simplexml backport ? in PHP_Compat ?
How there could be? The necessary language elements are not there. See for example http://www.ister.org/code/simplexml44/doc.xhtml
Did I hear DrupalXML library? But seriously, simpleXML is great. I'm sure I'm not the only one that would like to start taking advantage of it. If we want to continue supporting php4(which I think is necessary) and we want simpleXML then maybe we should write our own library that degrades to something like the system linked by Karoly. That way we have a common interface and we can take advantage of the benefits of simpleXML. And if we take some care in designing the library it will make conversion to simpleXML at php4 EOL fairly easy.
participants (11)
-
adrian rossouw -
Darrel O'Pry -
Dries Buytaert -
fago -
Gordon Heydon -
Greg Knaddison - GVS -
James Gilliland -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Richard Archer