Re: 5.4 moving forward

From: Date: Sun, 05 Jun 2011 22:27:02 +0000
Subject: Re: 5.4 moving forward
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
Hi!


On 2011-06-05, Pierre Joye<[email protected]>  wrote:

On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson<[email protected]>  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?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Thread (77 messages)

« previous php.internals (#52985) next »