Open Stack

Excerpts from Jeremy Stanley's message of 2016-03-25 12:50:04 +0000:
> On 2016-03-25 08:41:51 -0400 (-0400), Doug Hellmann wrote:
> > All of our projects are able to tag releases in master *and* stable
> > branches. We regularly release stable updates to libraries.
> > 
> > I'm embarrassed to say I don't know what the job you describe about
> > merging tags into master does. If the commit that was tagged on a stable
> > branch doesn't exist in master, what gets the tag in master? Or is the
> > stable branch commit merged back into master?
> 
> It was invented as a workaround for this problem:
> 
>     1. Create a new stable branch during the RC period.
>     2. Tag the first release on the new stable branch.
>     3. Compare dev versioning between new stable branch and master,
>        you'll see that master's version is lower because it contains
>        no record there's been a release tagged yet.
> 
> If the tag on the stable branch is higher than the tag on master, we
> merge the tag and its history into master but keep the current
> master branch state via this script:
> 
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/merge_tags.sh
> 
> It's possible that the logic there requires revisiting due to
> nuanced changes in our release model, but it should still be
> generally applicable.

OK. It looks like it grabs the tagged commit from the stable branch
and merges that back into master, expecting the results to be null
because we backport all changes to stable branches and don't introduce
anything new there. Is that right?

I think having the tags merged like that is going to confuse reno,
because I didn't expect us to be introducing a tag into the master
history that wasn't actually there. I'll have to experiment with
this to see if it really is a problem.

Doug