Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.224 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=pmpi+RoZY804IOWPS60PQom8NTxD/L4p6xbmSR8g1nVcp7VPCrVsk9awT7Aa47FRbz
         13VdDtiqiQGTV2QorbzI22oeky2M0UXoXfzRVRQk/YsApHMXekPvNsCtQCINxY2Mqzi3
         w2FpQThWBrKJKleny6Y1wuwUMA6pkJYW4dWG0=
MIME-Version: 1.0
In-Reply-To: <201003182220.29144.larry@garfieldtech.com>
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>
Date: Fri, 19 Mar 2010 09:31:49 +0100
Message-ID: <b54d0abe1003190131n7594cf74hbfdf511e54f8b42b@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
From: tyra3l@gmail.com (Ferenc Kovacs)

On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield <larry@garfieldtech.com> wr=
ote:
> On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
>
>> +1 For shorter release cycles. Shorter release cycles could also allow u=
s
>> =C2=A0to move major releases immediately to bug and security fixes only.=
 I've
>> =C2=A0never been a fan of seeing additional features added in minor rele=
ases.
>> =C2=A0It's confusing enough to try and keep track of features from one m=
ajor
>> =C2=A0release to the next, but then we add in features on minors as well=
. "That
>> =C2=A0feature was added in 5.3.1". Obviously this was not a good option =
when
>> =C2=A0major releases were at 12 months or more apart. If we can shorten =
the
>> =C2=A0cycle, I think it might be a good idea to visit how quickly each r=
elease
>> =C2=A0is frozen to bug and security fixes only. This may just be a devel=
opmental
>> =C2=A0pet-peave of mine, I'm sure I'll hear about it soon if the idea is
>> =C2=A0unfavorable.
>>
>> As an additional note to this, performance patches which don't add
>> additional features but only increase speed would still be fair game.
>>
>> P.S. 2: Reduced release cycle times might reduce the burdens on RMs as w=
ell
>> by allowing them to commit to shorter time periods of release management
>> responsibility. Not that I hear any of them complaining, just thinking t=
his
>> might be another good reason to give it a try.
>>
>> Eric Lee Stewart
>
> If I could step in for a moment, while there's certainly advantages to sh=
orter
> release cycles that others have mentioned there's another factor that has=
 to
> be considered: Backward compatibility would have to be much more tightly
> monitored.
>
> Out in the shared hosting world, we're at the mercy of web hosts and Linu=
x
> distributions. =C2=A0They don't like to upgrade stuff if they don't have =
to, and
> often times not even then. =C2=A0It wasn't that long ago that we needed a=
n
> industry-wide boycott, essentially, to force PHP 5 at all. =C2=A0Most hos=
ts aren't
> on 5.3 yet. =C2=A0That means any mass-market PHP projects (Wordpress, Dru=
pal,
> Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with 5.2=
 at
> best, and it may be some time before the "I don't have root on my server =
and
> don't know how to compile stuff myself" crowd (read: the vast majority of=
 the
> market) is able to leverage 5.3.
>
> When significant releases are 2-3 years apart, web hosts can expect to ha=
ve to
> put in actual work every couple of years and mass-market developers can e=
xpect
> to have to beat their hosts over the head with a stick every few years. =
=C2=A0If
> significant releases are going to be every year, then it has to still be =
easy
> and safe for hosts to upgrade. =C2=A0Preferably it has to also make serve=
rs faster
> because then they have an incentive to upgrade themselves. =C2=A0If hosts=
 don't
> upgrade, it doesn't matter what amazing new features PHP has. =C2=A0Most =
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.

Tyrael
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>