Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50525 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55987 invoked from network); 25 Nov 2010 14:05:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2010 14:05:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:51996] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 32/00-55895-A3D6EEC4 for ; Thu, 25 Nov 2010 09:05:50 -0500 Received: from localhost (xdebug.org [127.0.0.1]) by xdebug.org (Postfix) with ESMTPS id 0A48EDE13E; Thu, 25 Nov 2010 14:05:44 +0000 (GMT) Date: Thu, 25 Nov 2010 14:05:43 +0000 (GMT) X-X-Sender: derick@kossu.derickrethans.nl To: Davey Shafik cc: PHP Internals In-Reply-To: Message-ID: References: <73.C4.59959.876BBEC4@pb1.pair.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Re: Hold off 5.4 From: derick@php.net (Derick Rethans) On Thu, 25 Nov 2010, Davey Shafik wrote: > The goal then was to essentially take the 5.3 branch, create a 5.4 > branch, cherry pick commits to trunk and apply them to the 5.4 branch > and end up with a stable build. Unfortunately, subversion merging > sucks. This has nothing to do with any sort of version control sucking. Cherry picking is hard! It only works if you get one feature in one commit, instead of many several, with other changes in between, without many dependices between patches. PHP isn't like that, especially with Dmitry's engine changing patches. > This doesn't seem the ideal time to introduce a new toolchain, so > sticking with SVN, we should maintain 4 branches, 5.2 (security only), > 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC > breaks), 6.0 (BC breaks). Four branches? Are you going to help? > Non-agreed upon enhancements, potential BC breaks, all should be done > in feature branches. That's a good theoretical point of view. And I maintain it doesn't work. It makes it for example very difficult to try out multiple new features at the same time; to say, to try to figure our whethr your app will still works. It's also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible (that's also why I am not a fan of DVCS, because it reduces that exposure drastically). Derick