Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49241 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20579 invoked from network); 10 Aug 2010 08:45:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Aug 2010 08:45:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 217.114.211.66 as permitted sender) X-PHP-List-Original-Sender: johannes@php.net X-Host-Fingerprint: 217.114.211.66 ns.km36107.keymachine.de Solaris 10 (beta) Received: from [217.114.211.66] ([217.114.211.66:63320] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 31/F0-14965-8B1116C4 for ; Tue, 10 Aug 2010 04:45:45 -0400 Received: from [192.168.1.31] (ppp-93-104-43-196.dynamic.mnet-online.de [93.104.43.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id BDA6E24AAF; Tue, 10 Aug 2010 10:45:41 +0200 (CEST) To: Adam Harvey Cc: Pierre Joye , Kalle Sommer Nielsen , Internals In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: php.net Date: Tue, 10 Aug 2010 10:45:40 +0200 Message-ID: <1281429940.969.2093.camel@guybrush> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] 5.4 Alpha? From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote: > I could not disagree more. I think one of the key lessons we should > have learned out of the whole 6.0 saga was that "release early, > release often" is a good thing I will no support the release of trunk overly actively as long as the "type hints" are as they are but on a general note: Yes. Release early, release often is a good thing. What I'd also like is to have a Ubuntu-like support model. Where we have one LTS (long term supported) version (now for instance 5.3) which will get bug fixes for quite some time and an "early access" version (5.4) which will receive updates until the next "early access" (5.5) is there. Reasons: * Give people early access to features * Motivate developers as their additions are in a reachable future * Give users the chance to stay on the LTS version without having to do the full update on every release * Reduce the number of changes in "bugfix" releases the whole idea in ASCII art: Version Time -> 5.3 ****************+++++ 5.4 |***** 5.5 || ***** 5.6 || | ***** 6.0 || | | **************** 6.1 || | | | ***** || | | | | || | | | ^ Release date 6.1.0 || | | ^ Release 6.0.0, 5.3 goes to extended support (security only) || | ^ Release 5.6.0, 5.3 stays in support, 5.5 EOL || ^ Release 5.5.0, 5.3 stays in support, 5.4 EOL |^ Release 5.4.0, 5.3 stays in support ^ now So we'd always have three branches, while two only receive bug fixes, plus one branch for the next milestone. johannes