Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53024
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain gmail.com does not designate 208.113.200.5 as permitted sender)
Message-ID: <4DECE0DC.5050300@gmail.com>
Date: Mon, 06 Jun 2011 23:14:52 +0900
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: internals@lists.php.net
References: <4DE7F179.5010402@sugarcrm.com> <alpine.DEB.2.02.1106030843370.9040@whisky> <4DE89534.5070206@sugarcrm.com> <alpine.DEB.2.02.1106030920570.9040@whisky> <4DE89CD2.4040302@sugarcrm.com> <alpine.DEB.2.02.1106030937571.9040@whisky> <4DE9AA9B.3000108@sugarcrm.com> <BANLkTinxwduQXxBoLZuFzT_Wyfy-LGC6ZA@mail.gmail.com> <slrniunu3j.dic.dsp@experimentalworks.net> <4DEC02B6.60806@sugarcrm.com>
In-Reply-To: <4DEC02B6.60806@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 5.4 moving forward
From: davidkmuir@gmail.com (David Muir)

On 06/06/11 07:27, Stas Malyshev wrote:
> Hi!
>
>> On 2011-06-05, Pierre Joye<pierre.php@gmail.com>  wrote:
>>> On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson<philip@roshambo.org> 
>>> wrote:
>>>>> I'd to say that I'm very happy to finally see such discussions
>>>>> happening, let sort the base (99% is done by our existing RFC about
>>>>> release process, let adopt it already!) and move on with 5.4.
>>>>
>>>>
>>>> This is a prime example of what we're talking about. Several have
>>>> expressed a desire to follow an Ubuntu style of branching instead
>>>> of the style proposed in said RFC. This is a core issue, so the RFC
>>>> is certainly not ready to adopt.
>>>>
>>>> So does this require a new RFC, or do the RFC proposers feel this
>>>> is a key concept?
>
> I think that this RFC does not contain Ubuntu-style LTS and it doesn't
> look like it's author(s) support it, so it should be some different
> point, which may be RFCed and voted on if we see substantial support
> for it.
>
> Speaking of which, I personally don't understand how LTS thing would
> work in PHP. Does it mean we'd decide out of the blue that some
> version would have extended support, upfront? Like, say, we now say
> "5.5 would have extended support"? Why would we want to do this, how
> would we know it? E.g., I understand if we had an option of extending
> support for some version post-factum, e.g., somewhere in 2015 we'd say
> "5.4 is so damn good and 5.5 has so many substantial changes that now
> we want 5.4 support to be extended another couple of years, and we
> feel we have people that are willing to do it". We could then talk on
> it and decide it, nothing prevents it. But as I understand LTS model
> means we'd have to decide it now, in 2011, and I don't see how it
> works. Could some of the proponents on this model explain it?

Theoretical benefits of LTS:
1. You have a version that is supported for an extended period of time.
Possibly useful for Ubuntu LTS releases and RHEL and other distros that
have a >3 year lifetime.
2. Keeps disruptive changes coming in on an LTS release. The goal is
that LTS is the polished result of the prior non-LTS releases.
3. Makes hosting companies feel safer offering an LTS release as it
means less disruption for their users.
4. Businesses like it because it's less work for them to upgrade every
3-5 years instead of every 6-18 months.

Those are the ones I can think of.
Although I appreciate the model with my OS, I don't think it would work
well on the application/component level.

Cheers,
David