[openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

Clark Boylan cboylan at sapwetik.org
Tue Aug 4 16:28:00 UTC 2015



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.

Clark



More information about the OpenStack-dev mailing list