Re: [RFC] Poke releases, tags and branches

[Jose E. Marchesi]

Hi Dan.

>> Hi people!
>>
>> I intend to use the following releasing schema.
>>
>> We will start with a pre-release 0.90.  It will most likely be followed
>> by several other pre-releases 0.91, 0.92, ... until we are happy with
>> it.
>>
>> At that point, we will release 1.0, then 1.1 and so on.  When we feel
>> that we have a candidate for poke 2.0, then we will release the
>> pre-release 1.90, followed by pre-releases until 3.0 is ready.
>>
>> And so on...
>>
>> In terms of git repo, we will have branches for the series:
>>
>>   releases/poke-0
>>   releases/poke-1
>>   releases/poke-2
>>   ...
>
> I would propose to call these maintenance/poke-$version for better
> differentiation from tag names.

I would say the poke-N is explicit enough, but if more people agree with
using a different basename then I will obligue :)

>
>>
>> and then in each branch tags for the (pre) releases themselves:
>>
>>   releases/poke-0.90
>>   releases/poke-0.91
>>   ...
>>   releases/poke-1.0
>>   releases/poke-1.1
>>   ...
>>
>> So, once we open the serie poke-0 with this pre-release, there will be
>> always a current open series, say, poke version N.
>>
>> New series are always branched from `master'.  This means that fixes and
>> new features are to be added there, and then most likely
>> backported/cherry-picked to the current open serie, and maybe to
>> previous series too, depending on the fix and whether we want to support
>> them or not.
>
> I would suggest that we decide in which way and order patches should be
> moved between branches. E.g. should we first fix a bug on master and
> then cherry-pick to maintenance branches or rather fix it in the oldest
> maintenance branch first and then forward merge the patch to master?
> Both approaches work, we should just pick one.

I would say the first: apply in master then cherry-pick to release
branches when appropriate.