Open Stack

On 6/27/2014 7:44 AM, Thierry Carrez wrote:
> Hi everyone,
>
> Since the dawn of time, we have been using "milestone-proposed" branches
> for milestone and final release branches. Those would get
> milestone-critical and release-critical bugfixes backports, while the
> master branch can continue to be open for development.
>
> However, reusing the same blanket name for every such branch is causing
> various issues, especially around upgrade testing. It also creates havoc
> in local repositories which may have kept traces of previous
> incarnations of "milestone-proposed".
>
> For all those reasons, we decided at the last summit to use unique
> pre-release branches, named after the series (for example,
> "proposed/juno"). That branch finally becomes "stable/juno" at release
> time. In parallel, we abandoned the usage of release branches for
> development milestones, which are now tagged directly on the master
> development branch.
>
> The visible impact of this change will be apparent when we reach Juno
> RC1s. RC bugfixes will have to be backported to "proposed/juno" instead
> of "milestone-proposed". Tarballs automatically generated from this
> branch will be named PROJECT-proposed-juno.tar.gz instead of
> PROJECT-milestone-proposed.tar.gz. All relevant process wiki pages will
> be adapted to match the new names in the coming weeks.
>
> We are also generally changing[1] ACLs which used to apply to
> "milestone-proposed" branches so that they now apply to "proposed/*"
> branches. If you're a stackforge or non-integrated project which made
> use of milestone-proposed branches, you should probably switch to using
> "proposed/foo" branches when that patch lands.
>
> [1] https://review.openstack.org/#/c/102822/
>
> Regards,
>

We've been using a similar concept internally, we call it 
havana-proposed, icehouse-proposed, etc, but it sounds like the same 
idea.  We're supporting more than the last 2 stable releases and it's 
hard to tell when we need to quickly turn out a release candidate build 
(like for a security issue going back to Folsom or something), so it 
makes sense for us to try and avoid branch naming collisions.

Besides that branch naming we basically follow the same release process 
as upstream based on the same wiki's, with some additional automation 
for tagging and cleanup after the release.

-- 

Thanks,

Matt Riedemann