Open Stack

Excerpts from Chris Dent's message of 2016-03-24 17:25:33 +0000:
> On Thu, 24 Mar 2016, Alan Pevec wrote:
> 
> > Another example (not release:managed project but still) where we have
> > this confusion is gnocchi:
> > openstack/gnocchi > master $ python ./setup.py --version
> > 2.0.1.dev61
> > openstack/gnocchi > stable/2.0 $ python ./setup.py --version
> > 2.0.3.dev13
> 
> Sorry, I've never understood this feature of pbr (pre and post versioning
> is it?). Don't these problems go away if everyone just steps up and uses
> explicit version numbers in the projects (in __version__)[1].
> 
> No guessing required. No weird magic in pbr that few people
> understand.
> 
> If some kind of automatic control and validation is required, do it
> during the explicit tagging stage?
> 
> What is the goal of pre versioning?

Pre-versioning is what you're describing, declaring the version number
statically before releasing something. We use post-versioning, which is
to tag something that already exists to give it a version number (more
details in http://docs.openstack.org/developer/pbr/#version if you
care).

One goal is to have a single place where the version is declared,
and then to use that to derive the metadata that goes into the
distributable artifact created from the inputs. That's possible
with pre-versioning, by placing the version in setup.cfg, except
that you have to predict in advance what the right version number
is in order to get SemVer correct, and that requires managing what
types of patches you land in what order. For example, if you
pre-declare a bug-fix release X.Y.1 and then land a feature, your
version number is no longer correct and also needs to be updated.

That conflict leads us to things like updating the version number
when patches are submitted, which in turn leads to merge conflicts.
This issue was the source of the keyword-based bumping feature of
pbr, but using that also requires contributors to know about it and
remember to apply it and reviewers to remember to require it. It's
much less of a burden on the average contributor for us to just use
post-versioning and review what is being released and the tag being
applied to make sure the version is correct. That's what we've done
with the release automation this cycle.

> 
> [1] The fact that I can't look in the code for __version__ gives me
> rage face.

Having a __version__ inside the package actually has no bearing on
what version the packaging system thinks is associated with the
dist. The name is just a convention some projects have used. Rather
than hard-coding a value, it's better to use pkg_resources to ask
for the version of the current package.

Doug