Stefano Lattarini writes:
> So we should maybe go (after the next major release) with this naming
> scheme for the branches?
>
> * maint -> for next micro version
> * stable -> for next minor version
> * master -> for next major version
That seems to match common practice, insofar as I unde
On 2013-02-28 00:39, Stefano Lattarini wrote:
> On 02/28/2013 12:00 AM, Peter Rosin wrote:
>>
>> [SNIP]
>>
>> What I meant was that you can use (some of) my above proposed merges
>> to go forward with the new role for master instead of requiring help
>> from Savannah to allow rewriting master.
>>
>
Stefano Lattarini writes:
> And while you *might* have changed my mind before (because you have
> valid points, and maybe it would have better to err on the side of
> safety), I have now already rewritten maint, so rather than messing
> up by rewriting it again (to its old value, granted, but a re
Just that by far the most common branch setup in git repos seems to be
using master as the "dev trunk", with releases, release candidates
(etc) on special branches. There are often additional feature
branches for even more speculative changes, but master is generally
not really "safe," even if it'
On 02/23/2013 07:06 PM, Stefano Lattarini wrote:
>
>>> In a couple of days, I will proceed with this "branch moving":
>>>
>>>* branch-1.13.2 -> maint
>>>* maint -> master
>>>* master -> next
>>>
>> Done.
>>
> Damn, not really. For some questionable reason, Savannah is rejecting
> my no
On 02/25/2013 09:14 AM, Peter Rosin wrote:
> On 2013-02-23 19:06, Stefano Lattarini wrote:
>> On 02/23/2013 06:46 PM, Stefano Lattarini wrote:
>>> On 02/21/2013 04:06 PM, Stefano Lattarini wrote:
In a couple of days, I will proceed with this "branch moving":
* branch-1.13.2 -> mai
