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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev