Open Stack

Excerpts from Clark Boylan's message of 2015-08-04 09:28:00 -0700:
> 
> On Tue, Aug 4, 2015, at 06:22 AM, Doug Hellmann wrote:
> > 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?
> > 
> Sure, if we continue to use nova as the example, the current total
> number of tags present is:
> 
> clark at morbo:~/src/openstack/nova (master)$ git tag | wc -l
> 89
> 
> Which means for a single stable release we would more than double the
> total number of tags in the repo. Going from 89 tags to 387 tags without
> any additional information associated to those tags beyond "new commit"
> pollutes the tag ref space for humans. A computer can deal with 387 tags
> trivially, but it is harder for me to do so.

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?

Doug