Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73599 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85015 invoked from network); 5 Apr 2014 05:56:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Apr 2014 05:56:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:59566] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3A/20-16521-70B9F335 for ; Sat, 05 Apr 2014 00:56:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DDDA4140F52; Sat, 5 Apr 2014 01:56:20 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 63D4B140F53; Sat, 5 Apr 2014 01:56:20 -0400 (EDT) Message-ID: <533F9B03.4060302@sugarcrm.com> Date: Fri, 04 Apr 2014 22:56:19 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Kris Craig , =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= CC: Julien Pauli , PHP Internals References: <1396523991.2982.340.camel@guybrush> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Branching PHP6 From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > By release branch, are you referring to minor releases or maintenance > releases? If the latter, it'd be a moot point under this model because > we'd be getting rid of separate branches for maintenance releases > altogether. Instead, the RM would simply apply the tag to the commit where > they want the maintenance release to occur. That would be a much cleaner > approach than what we're doing now. It is not. Especially not when we have many people that can commit code in any moment. RM should be able to create a stable release branch and do all the release work in this branch knowing it is not going to change, it can be verified, and it can be amended with urgent fixes (or, sometimes, removing certain changes) without having to pull in all the delta of unverified code that happened in between. Tags are not meant for that, release branches are meant exactly for that. I see absolutely no reason why what we are doing now is in any way "unclean". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227