Open Stack

Excerpts from Alan Pevec's message of 2015-08-05 16:14:32 +0200:
> >> > > > To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80
> >> > > > (kilo) and Nova 10.0.218 (juno).
> >> > > I am not a fan of doing this second option at all. We would be polluting
> >> > > the ref space of our repos with redundant information making the output
> >> > > of `git tag` unusable to humans. If this was not redundant info and a
> >> > > tag of 11.0.80 provided more information than a generated version of
> >> > > 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.
> 
> It actual does: auto-tagged commit means it passed our CI hence
> project "stands behind it".
> PBR-generated Z-version could be just local change which has never
> seen any CI yet.
> 
> > Using pbr to generate versions avoids that problem, but introduces the
> > challenge of not being able to necessarily figure out which commit
> > corresponds to a given version number from the outside. Say I want to
> > check out version 11.0.80 for some reason (maybe .81 has a bug I don't
> > want to deploy). How do I do that without a tag?
> 
> That also, PBR-generated version is not universally reproducible.
> 
> So what about making auto-tagging on stable branches optional for projects:
> by default if project has a stable branch(es) they will get
> auto-tagging but project could also opt-out and push X.Y.Z tags
> themselves, via the same release process like Oslo and clients.

We intend to have that release process automated further, so why don't
we build this auto-tagging system to submit a patch to the releases
repository instead of doing the tag directly. That way we have the full
history for the release documentation we're planning to generate.

Doug