Open Stack

Excerpts from Clark Boylan's message of 2015-08-03 11:54:06 -0700:
> On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
> > Hi everyone,
> > 
> > A month ago the stable branch team decided to move away from
> > synchronized stable point releases and enable continuous stable branch
> > delivery instead.
> > 
> > The end goal is that every commit on a stable branch for a "service"
> > project will get a .Z version increment, and a tag be pushed to match.
> > So we'll have for example Nova 12.0.0 at Liberty release, and each
> > stable branch commit will result in 12.0.1, 12.0.2... versions.
> > 
> > In order to make this work, it looks like we'd require:
> > 
> > * pbr changes so that it supports a mode where every commit on the
> > branch increments .Z
> > 
> > * infra changes to automatically push the corresponding tag when the
> > commit is merged
> > 
> > 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.

One problem with dev versions that has been pointed out elsewhere
(by ttx?) is that it is difficult/impossible to distinguish between
11.0.0.dev80 on stable/kilo and a my-companys-patched/kilo branch,
since we're counting commits but the version doesn't actually depend
on the contents of those commits. Using explicit tags in our repo
endows those versions with a bit more "officialness".

I'm not sure why you see having more tags "polluting" the ref space, can
you elaborate on that?

Doug