Open Stack

Hi, so as everyone knows I've been on an arc to teach pbr a lot more
about the semantic versioning we say we use (for all things) - with
the API servers being different, but a common set of code driving it.

We realised there's one quirky interaction today: since we fixed the
bug where pbr would create versions older than the release:
https://bugs.launchpad.net/pbr/+bug/1206730 we've made the big-bang
release somewhat harder.

I don't think betas are affected, only actual releases, and only for
projects using 'preversioning' - thats the API servers, with a version
number in setup.cfg.

Here's what happens.

The two interacting rules are this:
 - pbr will now error if it tries to create a version number lower
than the last release (and releases are found via the git tags in the
branch).
 - pbr treats preversion version numbers as a hard target it has to use

When we make a release (say 2014.1.0), we tag it, and we now have
setup.cfg containing that version, and that version tagged.

The very next patch will be one patch *after* that version, so it has
to be a patch for the next release. That makes the minimum legitimate
release version 2014.1.1, and the local version number will be a dev
build so 2014.1.1.dev1.g$shahere.

But the target it is required to use is 2014.1.0 - so we get a dev
build of that (2014.1.0.dev1.g$shahere) - and thats lower than the
last release (2014.1.0) and thus we trigger the error.

So, if we tag an API server branch with the same version it has in the
branch, any patch that attempts to change that branch will fail,
unless that patch is updating the version number in setup.cfg.

This interacts with the release process: as soon as we tag say nova
with the release tag (not a beta tag), all changes to nova will start
erroring as the dev versions will be bad. When we then tag neutron,
the same will happen there - it will effectively wipe the gate queue
clean except for patches fixing the version numbers.

This is needless to say fairly disruptive. I had initially been
concerned it would wedge things entirely - but unaltered branches will
get the release tag version and be ok, so we can correct things just
by submitting the needed patches - we'll want to promote them to the
front of the queue, for obvious reasons.

Going forward:

* We could just do the above - tag and submit a version fix

* We could submit the version fix as soon as the release sha is
chosen, before the tag
  - we could also wait for the version fixes to land before tagging

* We could change pbr to not enforce this check again
  - or we could add an option to say 'I don't care'

* We could remove the version numbers from setup.cfg entirely

* We could change pbr to treat preversion versions as a *minimum*
rather than a *must-reach*.

I'm in favour of the last of those options. Its quite a conceptual
change from the current definition, which is why we didn't do it
initially. The way it would work is that when pbr calculates the
minimum acceptable version based on the tags and sem-ver: headers in
git history, it would compare the result to the preversion version,
and if the preversion version is higher, take that. The impact would
be that if someone lands an ABI break on a stable-release branch, the
major version would have to be bumped - and for API servers we don't
want that. *but* thats something we should improve in pbr anyway -
teach it how we map semver onto the API server projects [e.g. that
major is the first two components of 2014.1.0, and minor and patch are
bundled together into the third component.

The reason I prefer the last option over the second last, is that we
don't have any mechanism to skip versions other than tagging today -
and doing an alpha-0 tag at the opening of a new cycle just feels a
little odd to me.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud