Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42786 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34580 invoked from network); 22 Jan 2009 17:56:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jan 2009 17:56:30 -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 83.243.58.134 as permitted sender) X-PHP-List-Original-Sender: johannes@php.net X-Host-Fingerprint: 83.243.58.134 mailout2.netbeat.de Linux 2.6 Received: from [83.243.58.134] ([83.243.58.134:33613] helo=mailout2.netbeat.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8B/57-15341-D43B8794 for ; Thu, 22 Jan 2009 12:56:30 -0500 Received: (qmail 13404 invoked by uid 89); 22 Jan 2009 18:14:27 -0000 Received: from unknown (HELO ?192.168.1.103?) (johannes%schlueters.de@93.104.41.78) by mailout2.netbeat.de with ESMTPA; 22 Jan 2009 18:14:27 -0000 To: Pierre Joye Cc: Greg Beaver , PHP Developers Mailing List In-Reply-To: References: <49778369.4070709@chiaraquartet.net> <1232626789.5728.12.camel@goldfinger> Content-Type: text/plain Date: Thu, 22 Jan 2009 18:56:25 +0100 Message-ID: <1232646985.5728.306.camel@goldfinger> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC lite] implement import of functions in namespace From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Thu, 2009-01-22 at 13:38 +0100, Pierre Joye wrote: > > It's been a long time for 5.3 already ... let's try to make release > > cycles shorter, not longer! > > There is no pressure on us to push a release. Yes, if we decide to never release it's fine, but if we want to release ever we have to draw the line at some moment. In June or July traits were rejected since we want to release "soon" since then we go from minor delay to minor delay and Lukas and I think it's a good time to finally draw the line. > About removing the closure or anything else only because we want the > beta1 out this month is a bad choice and I strongly disagree with this > decision (if it happens). If we can agree on Christian's last proposal that's better if not I'd say (Lukas agrees) we make sure we have something releasable on which we can build "full closure OO support" lateron without breaking anything. (either making sure the closure implementation is in a state that we can add that stuff lateron without harm or, if nothing else helps, as last step, dropping them) >From time to time we have to make releases and focus on them. johannes