Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47433
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 69.5.8.4 cause and error)
Message-ID: <4BA3AC50.9020004@garfieldtech.com>
Date: Fri, 19 Mar 2010 11:54:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: internals@lists.php.net
References: <alpine.DEB.2.00.1003161545500.4153@kossu.derickrethans.nl>	 <042C5521-4AE9-477A-B182-31D5FFE08207@pooteeweet.org>	 <ce6b011c1003182005n7a2e31f8gc82dc9520684d2a6@mail.gmail.com>	 <201003182220.29144.larry@garfieldtech.com>	 <b54d0abe1003190131n7594cf74hbfdf511e54f8b42b@mail.gmail.com>	 <ffa0ace81003190812v152f56b6m5d0346deca850ebb@mail.gmail.com> <ce6b011c1003190834g496cbe17h1763595fc78363c2@mail.gmail.com>
In-Reply-To: <ce6b011c1003190834g496cbe17h1763595fc78363c2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
From: larry@garfieldtech.com ("larry@garfieldtech.com")

On 3/19/10 10:34 AM, Eric Stewart wrote:

>>>> When significant releases are 2-3 years apart, web hosts can expect to
>>> have to
>>>> put in actual work every couple of years and mass-market developers can
>>> expect
>>>> to have to beat their hosts over the head with a stick every few years.
>>>   If
>>>> significant releases are going to be every year, then it has to still
>> be
>>> easy
>>>> and safe for hosts to upgrade.  Preferably it has to also make servers
>>> faster
>>>> because then they have an incentive to upgrade themselves.  If hosts
>>> don't
>>>> upgrade, it doesn't matter what amazing new features PHP has.  Most
>>> people
>>>> can't use 'em.
>>>>
>>>> I'm not against a more planned, frequent release cycle but I want to
>> make
>>> sure
>>>> that the upgrade treadmill is kept walkable or else it won't matter
>> that
>>> PHP
>>>> has new features.
>>>>
>>> I think that the hosting companies will adapt as slow as they can, so
>>> if we give more frequent releases, then they will (have to) upgrade
>>> more often.
>>> Additionaly if we release more frequently but with fewer changes, then
>>> the developers can adapt more easily, because they have to watch out
>>> for one or two change at a time, not a whole lot of changes.
>>>
>>
>> Being a guy who both runs a small hosting shop and spends lots of time
>> doing
>> development.  I would greatly appreciate more frequent, but smaller
>> releases.  I just finally got 5.3 rolled out this week, and have been
>> wanting it for months for the performance improvements in realpath, but
>> have
>> been hindered by the large list of things it would throw warnings about.
>> The other side of hosting is that most of your clients don't keep on top of
>> versions of their installed software.  Even app developers don't want to go
>> make changes to a 5 year old app just because PHP has decided that
>> something
>> is no longer a good practice.  My guess is that I'm in the minority of
>> hosts
>> that want to upgrade PHP for new features.  Part of that is probably driven
>> by being a app developer for most of my job.
>>
>> --
>> -Nathan Gordon
>>
>> If the database server goes down and there is no code to hear it, does it
>> really go down?
>> <esc>:wq<CR>
>>
>
> I guess I'm missing the point on this. We all know hosting companies are
> slow to adopt our changes. But does it really have anything to do with the
> time interval between our releases. I would think the more pressing issue
> would be BC which is not a function of the time interval but rather a
> function of actual changes implemented in a release. I don't remember any
> one in this thread insinuating that we'll be making diversions from the long
> lasting goal of maintain BC whenever it's even remotely possible.
>
> Best case scenario when only considering the time interval. We see a little
> better adoption if short release cycles mean a new release gets push prior
> to a hosting company's evaluation period for rollout changes.
>
> Worst case scenario, a perception is generated by the fact we appear to be
> moving ahead faster and they appear to be falling behind even faster. But I
> think the reality will be that we are still doing roughly the same amount of
> changes either way. We'll just be pushing it out in smaller chunks.
>
> Eric Lee Stewart

The point is that, for instance, PHP 5.3 was not a trivial upgrade for 
coders or hosters.  Sure it's mostly compatible, and you certainly can 
write code that works from 5.0->5.3 just fine, and if not then you're 
probably doing something wrong... but that's most of the PHP code out 
there right now. :-)  And naturally you can't test your code against 5.3 
until it's out.

So things like "this didn't used to throw a warning but should have all 
along, so now it does" are BC breaks, from a hoster's point of view.  If 
they upgrade, some of the random code they host will start throwing 
warnings when it didn't used to.  So they don't upgrade, and Linux 
distros take their time (not everyone is as behind as Red Hat, but the 
current Ubuntu stable still ships 5.2 for instance), so devs who don't 
compile their own PHP can't really test on 5.3...  Nastiness.  That's 
what kept PHP 5 back for so long.

I guess my point is that one rough upgrade every 3-5 years is something 
hosts and coders can deal with, mostly.  Or one easy upgrade every 1-2 
years is something hosts and coders can deal with, mostly.  But a rough 
upgrade every 1-2 years is not something that most hosts and coders can 
keep up with.  And the definition of "rough" in this context is really 
strict.

So if non-bug releases are going to move from 3-5 years to 1-2 years, it 
also needs to be kept easy, not rough, which means a much tighter reign 
kept on BC breakage, even low-level "you should be doing it this way 
now" breakage.  The long-tail of versions that mass-market projects need 
to support is then much longer, too, so they need to be able to write 
code that will run smoothly on 5.2, 5.3, 5.4, and 5.5, even if they 
don't use anything not in 5.2.

Does that explain my concern better?

--Larry Garfield