Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48115 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81510 invoked from network); 27 Apr 2010 16:40:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Apr 2010 16:40:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 unknown Solaris 10 (beta) Received: from [217.114.211.66] ([217.114.211.66:63805] helo=schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/3A-60649-E6317DB4 for ; Tue, 27 Apr 2010 12:40:15 -0400 Received: from localhost (ka.local [127.0.0.1]) by schlueters.de (Postfix) with SMTP id C20A02423A for ; Tue, 27 Apr 2010 18:40:11 +0200 (CEST) Received: from [192.168.1.31] (ppp-93-104-47-38.dynamic.mnet-online.de [93.104.47.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by schlueters.de (Postfix) with ESMTPSA id EC6F424237; Tue, 27 Apr 2010 18:40:10 +0200 (CEST) To: Pierre Joye Cc: Gwynne Raskind , Ilia Alshanetsky , Kalle Sommer Nielsen , Lukas Kahwe Smith , Andi Gutmans , Derick Rethans , PHP Developers Mailing List In-Reply-To: References: <698DE66518E7CA45812BD18E807866CE03F16456@us-ex1.zend.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 27 Apr 2010 18:39:56 +0200 Message-ID: <1272386397.870.28.camel@guybrush> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] trunk is alive and open From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: > Before even thinking about a planning, we have to define what we want > in and how we go further. ACK, I think it makes sense to define some "key features" we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said "let's backport from 6 and add all stuff coming in". I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning "stable" but having an accepted design) make a release branch (either by branching of or locking trunk for "bigger" features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. johannes