<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ⇥ PHP 5.2 support ends just as its adoption begins</title>
	<atom:link href="http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=php-5-2-support-ends-just-as-its-adoption-begins</link>
	<description>Stumbling on since 1997</description>
	<lastBuildDate>Fri, 07 Oct 2011 08:06:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Wil Moore III</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1441</link>
		<dc:creator>Wil Moore III</dc:creator>
		<pubDate>Sat, 31 Jul 2010 15:48:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1441</guid>
		<description>“However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.”

@Marco:

IMO, framework developers are doing a good job here. If anything, it showcases the tenacity and devotion of the framework developers to provide a quality product rather than a product that &quot;just works&quot;.

Don&#039;t get me wrong, a product that works is a great feat (unfortunately) for a lot of shops; however, I do not believe it should be the final goal.

“...in public instead of mailing lists, with those end users instead of sitting on your own island.”

@Rene:

From what I gather, you are saying that because &quot;you&quot; and certain others do not care to utilize the _very_ _public_ resources available, these resources are somehow deemed _non-public_? I do not believe that is fair.

There are also plenty of commercial closed-source software and hardware products that use the same facilities to allow their users to congregate. In some cases they even charge for access. PHP provides this for free. Why is this not enough?

&quot;Drupal and WP strive for a broader target market...&quot;

@Mario:

Thus they allow the popularity contest to dictate the progress of their product. A better approach might be to make the software: 

1: easy to upgrade
2: easy to maintain
3: and most importantly, easy to extend (&#039;extend&#039; !== &#039;ugly hack&#039;)

I doubt this would make them less popular with their target market.

I personally wouldn&#039;t want to think that my software was popular only because it works with a majority of hosts. Kind of a cop-out goal that reeks of mediocrity.

&quot;Unasked for semantic and questionable syntax changes in point releases (!) don’t help either.&quot;

@Mario:

So, because &quot;you&quot; don&#039;t need it, no-one else does? I would recommend that you check out python, scala, .net, and ruby sometime. No, PHP isn&#039;t python, scala, .net, or ruby, but that doesn&#039;t mean PHP should close its eyes and pretend that there aren&#039;t good ideas out there that can be leveraged to make PHP even better.</description>
		<content:encoded><![CDATA[<p>“However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.”</p>
<p>@Marco:</p>
<p>IMO, framework developers are doing a good job here. If anything, it showcases the tenacity and devotion of the framework developers to provide a quality product rather than a product that &#8220;just works&#8221;.</p>
<p>Don&#8217;t get me wrong, a product that works is a great feat (unfortunately) for a lot of shops; however, I do not believe it should be the final goal.</p>
<p>“&#8230;in public instead of mailing lists, with those end users instead of sitting on your own island.”</p>
<p>@Rene:</p>
<p>From what I gather, you are saying that because &#8220;you&#8221; and certain others do not care to utilize the _very_ _public_ resources available, these resources are somehow deemed _non-public_? I do not believe that is fair.</p>
<p>There are also plenty of commercial closed-source software and hardware products that use the same facilities to allow their users to congregate. In some cases they even charge for access. PHP provides this for free. Why is this not enough?</p>
<p>&#8220;Drupal and WP strive for a broader target market&#8230;&#8221;</p>
<p>@Mario:</p>
<p>Thus they allow the popularity contest to dictate the progress of their product. A better approach might be to make the software: </p>
<p>1: easy to upgrade<br />
2: easy to maintain<br />
3: and most importantly, easy to extend (&#8216;extend&#8217; !== &#8216;ugly hack&#8217;)</p>
<p>I doubt this would make them less popular with their target market.</p>
<p>I personally wouldn&#8217;t want to think that my software was popular only because it works with a majority of hosts. Kind of a cop-out goal that reeks of mediocrity.</p>
<p>&#8220;Unasked for semantic and questionable syntax changes in point releases (!) don’t help either.&#8221;</p>
<p>@Mario:</p>
<p>So, because &#8220;you&#8221; don&#8217;t need it, no-one else does? I would recommend that you check out python, scala, .net, and ruby sometime. No, PHP isn&#8217;t python, scala, .net, or ruby, but that doesn&#8217;t mean PHP should close its eyes and pretend that there aren&#8217;t good ideas out there that can be leveraged to make PHP even better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wim Godden</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1436</link>
		<dc:creator>Wim Godden</dc:creator>
		<pubDate>Thu, 29 Jul 2010 15:03:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1436</guid>
		<description>Giving the limited amount of backward incompatibilities in PHP 5.3, I don&#039;t really see a problem in ending PHP 5.2 development. Testing for PHP 5.3 compatibility can be somewhat automated as well through a set of CodeSniffer rules I wrote (see http://github.com/wimg/PHP53Compat_CodeSniffer), although it doesn&#039;t cover everything ofcourse.
If we want to get rid of the version fragmentation in the PHP hosting world, we need to either make sure that multiple versions of PHP can run within a single environment (which can be tricky and too challenging for most hosting providers) or force people to keep updated at least to the minor releases (arguably this should be called a major release since we&#039;re not getting PHP 6 anytime soon).
Anyone arguing that a x.x.3 release is &#039;not enough releases&#039; to ensure &quot;it&#039;s stable enough&quot; should look at the release date (5.3.0 was released in June 2009) and how many large hosts have been running PHP 5.3 for almost a year now.
Let&#039;s not forget the very nature of PHP is that it follows whatever the market needs as quickly as possible. If hosting providers don&#039;t keep up with what the market needs, they will loose customers. So upgrading to PHP 5.3 should be a priority for them, perhaps not on all their servers (some customers might have incompatible code after all), but at least on some.</description>
		<content:encoded><![CDATA[<p>Giving the limited amount of backward incompatibilities in PHP 5.3, I don&#8217;t really see a problem in ending PHP 5.2 development. Testing for PHP 5.3 compatibility can be somewhat automated as well through a set of CodeSniffer rules I wrote (see <a href="http://github.com/wimg/PHP53Compat_CodeSniffer" rel="nofollow">http://github.com/wimg/PHP53Compat_CodeSniffer</a>), although it doesn&#8217;t cover everything ofcourse.<br />
If we want to get rid of the version fragmentation in the PHP hosting world, we need to either make sure that multiple versions of PHP can run within a single environment (which can be tricky and too challenging for most hosting providers) or force people to keep updated at least to the minor releases (arguably this should be called a major release since we&#8217;re not getting PHP 6 anytime soon).<br />
Anyone arguing that a x.x.3 release is &#8216;not enough releases&#8217; to ensure &#8220;it&#8217;s stable enough&#8221; should look at the release date (5.3.0 was released in June 2009) and how many large hosts have been running PHP 5.3 for almost a year now.<br />
Let&#8217;s not forget the very nature of PHP is that it follows whatever the market needs as quickly as possible. If hosting providers don&#8217;t keep up with what the market needs, they will loose customers. So upgrading to PHP 5.3 should be a priority for them, perhaps not on all their servers (some customers might have incompatible code after all), but at least on some.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mario</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1434</link>
		<dc:creator>mario</dc:creator>
		<pubDate>Thu, 29 Jul 2010 08:45:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1434</guid>
		<description>Drupal and WP strive for a broader target market. And market reality just is that most hosting providers haven&#039;t migrated to PHP 5.3 yet, nor will they till the end of the year. It&#039;s no failure of downstream application developers not to force version upgrades. Obviously it&#039;s easier to rely on established PHP support than to deal with incompatibility woes and user complaints.

If PHP.net developers want to deal out blame, there&#039;s a good point to start. Neglecting proper language design and 5.3 support for APC et al contributes to the slow adoption curve. Unasked for semantic and questionable syntax changes in point releases (!) don&#039;t help either. And API compatibility is not seldomly hampered by random new parameters for established base functions. Avoidance is a good strategy if spurious development bumps that simply trouble your user base.

I don&#039;t believe php.net is able to fix its hen and egg version progress problem. Their point release feature onhobbling strategy clearly failed.</description>
		<content:encoded><![CDATA[<p>Drupal and WP strive for a broader target market. And market reality just is that most hosting providers haven&#8217;t migrated to PHP 5.3 yet, nor will they till the end of the year. It&#8217;s no failure of downstream application developers not to force version upgrades. Obviously it&#8217;s easier to rely on established PHP support than to deal with incompatibility woes and user complaints.</p>
<p>If PHP.net developers want to deal out blame, there&#8217;s a good point to start. Neglecting proper language design and 5.3 support for APC et al contributes to the slow adoption curve. Unasked for semantic and questionable syntax changes in point releases (!) don&#8217;t help either. And API compatibility is not seldomly hampered by random new parameters for established base functions. Avoidance is a good strategy if spurious development bumps that simply trouble your user base.</p>
<p>I don&#8217;t believe php.net is able to fix its hen and egg version progress problem. Their point release feature onhobbling strategy clearly failed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Freeaqingme</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1430</link>
		<dc:creator>Freeaqingme</dc:creator>
		<pubDate>Thu, 29 Jul 2010 02:35:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1430</guid>
		<description>&quot;The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world,&quot;

&quot;However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.&quot;

That doesn&#039;t mean fw makers should participate less, it means that large user communities like Drupal, WordPress, etc should participate more.

&quot;Common, get real people… try communicating upfront, in public instead of mailing lists, with those end users instead of sitting on your own island.&quot; (Rene)

How is a _public_ mailinglist/newsgroup not public? Everybody is able to follow discussions on news.php.net/php.internals, and get involved as he/she wishes.</description>
		<content:encoded><![CDATA[<p>&#8220;The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world,&#8221;</p>
<p>&#8220;However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.&#8221;</p>
<p>That doesn&#8217;t mean fw makers should participate less, it means that large user communities like Drupal, WordPress, etc should participate more.</p>
<p>&#8220;Common, get real people… try communicating upfront, in public instead of mailing lists, with those end users instead of sitting on your own island.&#8221; (Rene)</p>
<p>How is a _public_ mailinglist/newsgroup not public? Everybody is able to follow discussions on news.php.net/php.internals, and get involved as he/she wishes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Duane Gran</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1423</link>
		<dc:creator>Duane Gran</dc:creator>
		<pubDate>Tue, 27 Jul 2010 17:23:26 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1423</guid>
		<description>This may actually help adoption of 5.2 on some platforms.  At present 5.1.6 is considered the production release for CentOS.  This annoys me to no end, but now that 5.2 will only be updated for security reasons it stands to reason that the next release of CentOS will support it since it is feature-frozen.

While many of us knee-deep in PHP land can&#039;t fathom running older releases, this is likely a good thing to move along the glacier of supported releases.  It is good that someone is conservative in what release point they support.</description>
		<content:encoded><![CDATA[<p>This may actually help adoption of 5.2 on some platforms.  At present 5.1.6 is considered the production release for CentOS.  This annoys me to no end, but now that 5.2 will only be updated for security reasons it stands to reason that the next release of CentOS will support it since it is feature-frozen.</p>
<p>While many of us knee-deep in PHP land can&#8217;t fathom running older releases, this is likely a good thing to move along the glacier of supported releases.  It is good that someone is conservative in what release point they support.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve High</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1422</link>
		<dc:creator>Steve High</dc:creator>
		<pubDate>Tue, 27 Jul 2010 17:07:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1422</guid>
		<description>I&#039;m hearing way too much &#039;not our problem&#039; from people who are directly involved with the future of PHP.  That is a bit disappointing, because although your arguments are perfectly valid, your approaches do not qualify you as ambassadors to the language.  Whether you want that title or not, it doesnt matter, because as the most public faces of PHP, you are by your actions either attracting developers or shunning them.

Just sayin.</description>
		<content:encoded><![CDATA[<p>I&#8217;m hearing way too much &#8216;not our problem&#8217; from people who are directly involved with the future of PHP.  That is a bit disappointing, because although your arguments are perfectly valid, your approaches do not qualify you as ambassadors to the language.  Whether you want that title or not, it doesnt matter, because as the most public faces of PHP, you are by your actions either attracting developers or shunning them.</p>
<p>Just sayin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Heine</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1421</link>
		<dc:creator>Heine</dc:creator>
		<pubDate>Tue, 27 Jul 2010 13:38:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1421</guid>
		<description>Why drag Drupal into this?

Drupal and other CMSes need to run on a large variety of hosts. 

Drupal 7 runs on 5.3 just fine. 5.2 is simply the minimum requirement.</description>
		<content:encoded><![CDATA[<p>Why drag Drupal into this?</p>
<p>Drupal and other CMSes need to run on a large variety of hosts. </p>
<p>Drupal 7 runs on 5.3 just fine. 5.2 is simply the minimum requirement.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Les</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1419</link>
		<dc:creator>Les</dc:creator>
		<pubDate>Mon, 26 Jul 2010 16:34:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1419</guid>
		<description>As I understand it, PHP5.2 has been around for a while now and if WP et al are unable to maintain the status quo by moving with the times then tough.

My hosts are moving to PHP5.3 from PHP5.2 and about time too IMHO - why should the world stop for WP et al? Wouldn&#039;t we all be well screwed if we followed the (bad) practices of the mortley WP crew?!

F@@@ them [WP et al] I say...</description>
		<content:encoded><![CDATA[<p>As I understand it, PHP5.2 has been around for a while now and if WP et al are unable to maintain the status quo by moving with the times then tough.</p>
<p>My hosts are moving to PHP5.3 from PHP5.2 and about time too IMHO &#8211; why should the world stop for WP et al? Wouldn&#8217;t we all be well screwed if we followed the (bad) practices of the mortley WP crew?!</p>
<p>F@@@ them [WP et al] I say&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rene</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1418</link>
		<dc:creator>Rene</dc:creator>
		<pubDate>Mon, 26 Jul 2010 12:35:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1418</guid>
		<description>@Sebastian &quot;Just like any of the downstream projects, PHP is built by volunteers. These volunteers should not have to waste their limited resources to maintain old versions of PHP.&quot;

Are you from outer space or just a little bit ignorant? 

The majority of PHP end-users, are those downstream project users!  

Sure php developers should not waste their precious time in supporting large numbers of end users. Why would they, it&#039;s not their fault that the downstream project can&#039;t keep up with the fire arrow  alike movements of the php developers. (Cancellation of PHP6, sudden remove of PHP5.2 support, NO UTF8, YES UTF8, oh sorry NO UTF8 again etc. etc.) 

Common, get real people... try communicating upfront, in public instead of mailing lists,  with those end users instead of sitting on your own island. 

The power of PHP lies for a big part in those downstream projects, and un announced moves like these are really bad for the enterprise ready name PHP is trying to get. I say trying, cause i can assure you that doing things like this is not going to help a language become enterprise accepted. 

Enterprise maintainers and system administrators simply can not afford to upgrade a entire ecosystem just because a bunch of developers suddenly decide they can not waste their oh so precious time on a supporting a &#039;ancient&#039; language, and like to introduce new features that throw nice warnings at the end user that something is deprecated.

Having said this, i agree that some downstream project are ignorant to, common support for php4 should not be in a modern project. PHP4 is dead.. but really dead! 

However this method of forcing projects to PHP 5.3, by stopping active support for 5.2 and stating that security is going to fixed if developers find the need for it. 

Sure i can understand the reasons. And i&#039;am upgrading my projects as well, cause i do see the advantages of PHP 5.3. (especially the PHP-FPM including in 5.3.3)</description>
		<content:encoded><![CDATA[<p>@Sebastian &#8220;Just like any of the downstream projects, PHP is built by volunteers. These volunteers should not have to waste their limited resources to maintain old versions of PHP.&#8221;</p>
<p>Are you from outer space or just a little bit ignorant? </p>
<p>The majority of PHP end-users, are those downstream project users!  </p>
<p>Sure php developers should not waste their precious time in supporting large numbers of end users. Why would they, it&#8217;s not their fault that the downstream project can&#8217;t keep up with the fire arrow  alike movements of the php developers. (Cancellation of PHP6, sudden remove of PHP5.2 support, NO UTF8, YES UTF8, oh sorry NO UTF8 again etc. etc.) </p>
<p>Common, get real people&#8230; try communicating upfront, in public instead of mailing lists,  with those end users instead of sitting on your own island. </p>
<p>The power of PHP lies for a big part in those downstream projects, and un announced moves like these are really bad for the enterprise ready name PHP is trying to get. I say trying, cause i can assure you that doing things like this is not going to help a language become enterprise accepted. </p>
<p>Enterprise maintainers and system administrators simply can not afford to upgrade a entire ecosystem just because a bunch of developers suddenly decide they can not waste their oh so precious time on a supporting a &#8216;ancient&#8217; language, and like to introduce new features that throw nice warnings at the end user that something is deprecated.</p>
<p>Having said this, i agree that some downstream project are ignorant to, common support for php4 should not be in a modern project. PHP4 is dead.. but really dead! </p>
<p>However this method of forcing projects to PHP 5.3, by stopping active support for 5.2 and stating that security is going to fixed if developers find the need for it. </p>
<p>Sure i can understand the reasons. And i&#8217;am upgrading my projects as well, cause i do see the advantages of PHP 5.3. (especially the PHP-FPM including in 5.3.3)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shahar Evron</title>
		<link>http://blog.tabini.ca/2010/07/php-5-2-support-ends-just-as-its-adoption-begins/comment-page-1/#comment-1417</link>
		<dc:creator>Shahar Evron</dc:creator>
		<pubDate>Mon, 26 Jul 2010 06:28:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.tabini.ca/?p=820#comment-1417</guid>
		<description>@Jim check out the 5.3 Loader versions at http://forums.zend.com/viewtopic.php?f=57&amp;t=6595, post in that forum (not here) if you have questions.</description>
		<content:encoded><![CDATA[<p>@Jim check out the 5.3 Loader versions at <a href="http://forums.zend.com/viewtopic.php?f=57&#038;t=6595" rel="nofollow">http://forums.zend.com/viewtopic.php?f=57&#038;t=6595</a>, post in that forum (not here) if you have questions.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

