Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: neutral (athena.apache.org: 76.96.62.32 is neither permitted nor
 denied by domain of jim@jagunet.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
Subject: Re: A question (or two) of procedure, etc.
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <5049DD36.40405@hates.ms>
Date: Fri, 7 Sep 2012 08:15:28 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <867CED1B-7A7B-4E52-91F6-897D4E04FB40@jaguNET.com>
References: <5048E63F.8090603@hates.ms> <wfsjav0zgx.fsf@gmail.com>
 <50496333.2080004@gmail.com> <5049DD36.40405@hates.ms>
To: dev@stdcxx.apache.org

Many projects have CTR on trunk and RTC (based on trunk revisions)
to branch. This works well.

On Sep 7, 2012, at 7:40 AM, Liviu Nicoara <nikkoara@hates.ms> wrote:

> 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
>