Open Stack

Doug Hellmann wrote:
> Excerpts from John Dickinson's message of 2016-06-08 11:30:03 -0700:
>> Isn't the reason that the branch is merged back in because otherwise per can't generate a valid version number?
>
> I don't think it's related to versions being "valid," but to making
> things feel less confusing to human consumers at the expense of
> (what I think is) giving a misleading picture of the version history.
>
> We started merging the tags between branches because the version
> that ends up in the tarball generated from patches merging into
> master is lower than the version in the tarball generated from the
> stable branch, after the stable branch has received the "final" tag
> for the release (master still has a 0rc1 tag for the same version
> that is final on the branch). This is confusing to humans, but if
> those humans have not set up automated systems to install or otherwise
> consume artifacts for the same project from multiple branches it
> should not confuse any computers.

IIRC we started merging tags back so that the humans would not be 
surprised that "git tags" would return something like:

...
12.0.0.0b3
12.0.0.0rc1
13.0.0.0b1
...

i.e. the release would never be there. This was especially confusing 
back when we used an hybrid release model for Swift, where intermediary 
releases would be directly tagged but the "final" one would use a 
release candidates on a release branch, resulting in something weird 
like this when looking at master:

...
1.5.0
1.5.1
1.5.2rc1
1.6.0
...

We don't do this hybrid anymore for intermediary-released projects, 
everything is tagged directly. So you might still be missing stable 
release tags when running git tags on master, but while that may still 
be slightly confusing to humans, it's not as bad as the weird output above.

-- 
Thierry Carrez (ttx)