[openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

Robert Collins robertc at robertcollins.net
Wed Jul 29 17:21:32 UTC 2015

On 30 July 2015 at 01:39, Sean Dague <sean at dague.net> wrote:

> So, after every release a giant amount of patches all have to land lock
> step or everything is broken?

No, its not that bad.

The *tagged* commit is fine forever.

The *first* commit in each branch has to be the identification of the
new version in that branch.

So there is no race, and as long as you put up the new patch straight
away (which is AIUI part of the release manager process), everyone
else can Depends-On: I.... that patch, and things will be sane.

That said, yes, removing the version= line as unnecessary should make
things a lot simpler.

The change in pbr 0.11 was to fix a bug: the bug was that when there
is a version in setup.cfg, and a tag thats equal or higher, there are
no versions to pick from by the backwardly defined rules for
setup.cfg: the old code happily generated versions *IN THE PAST*. The
new code had a choice:
 - error
 - decide it knew better than the owner of setup.cfg and start
incrementing versions above it

At the time we chose to error, based on the reasoning that:
 - there was already a process to put new versions in setup.cfg at release time
 - the gate wouldn't be broken at all because its self checking
 - overriding pre-versioning seemed against the entire *intent* of

If a bunch of folk are going to say 'hey, we want a knob to make this
take the 'decide pbr knows better' path, I'm entirely willing to
support just changing the decision from 'error' to 'decide it knows
better'. It was arbitrary but conservative.

However - see above - I think the impact of the release is being
overstated. If I have that wrong, please help me understand whats
happened here.


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

More information about the OpenStack-dev mailing list