From dev-return-8659-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Fri Sep 7 11:40:05 2012 Return-Path: X-Original-To: apmail-stdcxx-dev-archive@www.apache.org Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2E7E7D4ED for ; Fri, 7 Sep 2012 11:40:05 +0000 (UTC) Received: (qmail 37600 invoked by uid 500); 7 Sep 2012 11:40:05 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 37564 invoked by uid 500); 7 Sep 2012 11:40:05 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 37554 invoked by uid 99); 7 Sep 2012 11:40:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 11:40:04 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [64.34.174.152] (HELO hates.ms) (64.34.174.152) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Sep 2012 11:39:55 +0000 Received: from [192.168.72.105] (unknown [166.57.38.196]) by hates.ms (Postfix) with ESMTPSA id 3ACCD45C09D for ; Fri, 7 Sep 2012 11:39:35 +0000 (UTC) Message-ID: <5049DD36.40405@hates.ms> Date: Fri, 07 Sep 2012 07:40:38 -0400 From: Liviu Nicoara User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: A question (or two) of procedure, etc. References: <5048E63F.8090603@hates.ms> <50496333.2080004@gmail.com> In-Reply-To: <50496333.2080004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/06/12 23:00, Martin Sebor wrote: >> Every project has certain branch strategy, I'm not sure about this so >> maybe Martin can advice. I prefer to develop on trunk and cherry pick >> to the other branches avoiding bulk merges (and that's in both >> directions). > > We've done most work on 4.2.x for historical reasons. I think > a better strategy is to develop, as you suggest, on trunk which > has the least restrictive commit policy, and merge changes out > to the more restrictive branches as appropriate. If open to voting, I am for trunk first, branches later. Liviu