Re: [RFC] Poke releases, tags and branches

[Dan Čermák]

Hi Jose,

"Jose E. Marchesi" <jemarch@gnu.org> writes:

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

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


Cheers,

Dan

signature.asc
Description: PGP signature