<?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/"
	xmlns:series="http://unfoldingneurons.com/"
		>
<channel>
	<title>Comments on: Upgrades In Open Source</title>
	<atom:link href="http://www.brandonsavage.net/upgrades-in-open-source/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brandonsavage.net/upgrades-in-open-source/</link>
	<description>The personal blog of Brandon Savage. Contains entries of a personal and professional nature focusing on PHP, Apple, LAMP, MySQL and Washington, DC.</description>
	<lastBuildDate>Fri, 03 Feb 2012 19:36:33 -0500</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: denderello</title>
		<link>http://www.brandonsavage.net/upgrades-in-open-source/#comment-2995</link>
		<dc:creator>denderello</dc:creator>
		<pubDate>Tue, 09 Mar 2010 17:14:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=1181#comment-2995</guid>
		<description>Great post! I must admit that although I&#039;m totally thrilled about the new PHP 5.3 version it&#039;s still a hard decision to switch completely to it.

But I wouldn&#039;t only limit this to Open Source projects. Even in companies working with PHP, Frameworks, Libraries, etc. you will face this problems, too. As an example you will have customers that don&#039;t want to upgrade their software just because it runs on a new PHP version.

Because of all this we are working on a plan atm to run multiple PHP version to make the switch as smooth as possible at the company I&#039;m working for.</description>
		<content:encoded><![CDATA[<p>Great post! I must admit that although I&#8217;m totally thrilled about the new PHP 5.3 version it&#8217;s still a hard decision to switch completely to it.</p>
<p>But I wouldn&#8217;t only limit this to Open Source projects. Even in companies working with PHP, Frameworks, Libraries, etc. you will face this problems, too. As an example you will have customers that don&#8217;t want to upgrade their software just because it runs on a new PHP version.</p>
<p>Because of all this we are working on a plan atm to run multiple PHP version to make the switch as smooth as possible at the company I&#8217;m working for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Veidit</title>
		<link>http://www.brandonsavage.net/upgrades-in-open-source/#comment-2994</link>
		<dc:creator>Veidit</dc:creator>
		<pubDate>Tue, 09 Mar 2010 16:22:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=1181#comment-2994</guid>
		<description>I think that Redhat Enterprise 6 will support php 5.2 in it&#039;s packages so that&#039;s what I am aiming for.
Waiting a few years for 5.3 is OK for me.</description>
		<content:encoded><![CDATA[<p>I think that Redhat Enterprise 6 will support php 5.2 in it&#8217;s packages so that&#8217;s what I am aiming for.<br />
Waiting a few years for 5.3 is OK for me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://www.brandonsavage.net/upgrades-in-open-source/#comment-2988</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Mon, 08 Mar 2010 13:59:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=1181#comment-2988</guid>
		<description>There is actually two problems here - one being existing projects and their migration to a new platform and the other being a new project with no established base. They each have their own paths to travel and decisions to be made.

If a new project is starting up they have the ability to say &quot;I&#039;m only supporting PHP 5.3&quot; they won&#039;t catch much guff. That project can dictate what they want to do and yes, they might loose some users because shared hosts won&#039;t upgrade, but the overall net gain as PHP 5.3 increases in market share means less support up front and possibly a better position down the road.

The other types of projects, like Zend Framework, normally will have an established maintenance plan in place. New whiz-bang features will slowly move from being in the older 1.x branch to 2.x, but that doesn&#039;t mean development won&#039;t completely stop on 1.x. Security patches and general bug fixes will still happen until that branch can formally put out to pasture as per the maintenance plan. 

The whole version argument really hits home with enterprises. Look at all the people running Redhat that are still on 5.1.x all because their managers don&#039;t want to leave the supported versions RHEL has established. In those cases though, they probably aren&#039;t running bleeding edge software anyway so again, not a huge impact. The more agile enterprises will already be planning their 5.3 migration (I know I am) and won&#039;t have a problem with software that is 5.3 only.

(There is also the fact that most well-written 5.2 code will run fine without any modifications will run in 5.3, so its more of a political and business issue than a technical one in my mind).</description>
		<content:encoded><![CDATA[<p>There is actually two problems here &#8211; one being existing projects and their migration to a new platform and the other being a new project with no established base. They each have their own paths to travel and decisions to be made.</p>
<p>If a new project is starting up they have the ability to say &#8220;I&#8217;m only supporting PHP 5.3&#8243; they won&#8217;t catch much guff. That project can dictate what they want to do and yes, they might loose some users because shared hosts won&#8217;t upgrade, but the overall net gain as PHP 5.3 increases in market share means less support up front and possibly a better position down the road.</p>
<p>The other types of projects, like Zend Framework, normally will have an established maintenance plan in place. New whiz-bang features will slowly move from being in the older 1.x branch to 2.x, but that doesn&#8217;t mean development won&#8217;t completely stop on 1.x. Security patches and general bug fixes will still happen until that branch can formally put out to pasture as per the maintenance plan. </p>
<p>The whole version argument really hits home with enterprises. Look at all the people running Redhat that are still on 5.1.x all because their managers don&#8217;t want to leave the supported versions RHEL has established. In those cases though, they probably aren&#8217;t running bleeding edge software anyway so again, not a huge impact. The more agile enterprises will already be planning their 5.3 migration (I know I am) and won&#8217;t have a problem with software that is 5.3 only.</p>
<p>(There is also the fact that most well-written 5.2 code will run fine without any modifications will run in 5.3, so its more of a political and business issue than a technical one in my mind).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Kary</title>
		<link>http://www.brandonsavage.net/upgrades-in-open-source/#comment-2987</link>
		<dc:creator>John Kary</dc:creator>
		<pubDate>Mon, 08 Mar 2010 13:51:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.brandonsavage.net/?p=1181#comment-2987</guid>
		<description>I think your approach to this from an open-source angle is interesting, because it really applies to everyone in software development: both open and closed-source. I think of a company like Adobe, which rarely issues bug/exploit patches for old versions of their software. They have no LTS (Long Term Support) version for their software; it&#039;s whatever version was last released. Think of Adobe&#039;s install base for something like Acrobat Reader or Photoshop. Do they not issue a LTS release because it might hurt business? Why not just require users to upgrade to stay current?

Related to your first point about WordPress, is WordPress in the same boat as Microsoft was with IE6? Are we going to see a 6-year drought between any real progress or an increase in minimum recommendations just because their user base is &quot;too big to fail?&quot; Not making a necessary change because it would affect too many people is like not ending a marriage because it would hurt too many other people.

This &quot;getting away with&quot; requiring PHP 5.3 is hot air. If anything, the next version of WordPress SHOULD require a modern PHP version so it can lend itself to modern best practices and enhanced security. Being such a widely used application, that alone should be paramount. If the core WordPress developers started on a new version of WordPress requiring PHP 5.3, by the time it&#039;s done, 5.3 might have more adoption. This is exactly the mindset of major framework developers for symfony and Zend Framework.</description>
		<content:encoded><![CDATA[<p>I think your approach to this from an open-source angle is interesting, because it really applies to everyone in software development: both open and closed-source. I think of a company like Adobe, which rarely issues bug/exploit patches for old versions of their software. They have no LTS (Long Term Support) version for their software; it&#8217;s whatever version was last released. Think of Adobe&#8217;s install base for something like Acrobat Reader or Photoshop. Do they not issue a LTS release because it might hurt business? Why not just require users to upgrade to stay current?</p>
<p>Related to your first point about WordPress, is WordPress in the same boat as Microsoft was with IE6? Are we going to see a 6-year drought between any real progress or an increase in minimum recommendations just because their user base is &#8220;too big to fail?&#8221; Not making a necessary change because it would affect too many people is like not ending a marriage because it would hurt too many other people.</p>
<p>This &#8220;getting away with&#8221; requiring PHP 5.3 is hot air. If anything, the next version of WordPress SHOULD require a modern PHP version so it can lend itself to modern best practices and enhanced security. Being such a widely used application, that alone should be paramount. If the core WordPress developers started on a new version of WordPress requiring PHP 5.3, by the time it&#8217;s done, 5.3 might have more adoption. This is exactly the mindset of major framework developers for symfony and Zend Framework.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk: basic (Feed is rejected)
Page Caching using disk: enhanced (User agent is rejected)
Database Caching 4/11 queries in 0.027 seconds using disk: basic
Content Delivery Network via Amazon Web Services: S3: files.brandonsavage.net.s3.amazonaws.com

Served from: www.brandonsavage.net @ 2012-02-07 04:14:36 -->
