[openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors

Steve Baker sbaker at redhat.com
Sun May 3 20:59:28 UTC 2015


On 02/05/15 07:06, Robert Collins wrote:
> On 2 May 2015 at 04:17, Doug Hellmann <doug at doughellmann.com> wrote:
>> Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:
>>> pbr 0.11 is finally released (now that Kilo is out :).
>>>
>>> This brings in more support to ensure that our version numbers are
>>> monotonically increasing.
>>>
>>> Mostly this should be unintrusive (but please do read the docs -
>>> http://docs.openstack.org/developer/pbr/#version).
> ...
>
>> It would be good to make sure this is in the pbr documentation, too.
> It is, at the link I gave. If its not clear enough, please do help me
> understand how, since having clear docs is kindof important :)
>
> I'd also like to do a little postmortem - here's the fallout I've
> heard of from pbr's 0.11 release (which is > 1yr of inventory, so
> kindof a big deal).
>
...
>
> Lastly, and still unresolved, heat's contrib plugin versions
> (introduced in March) are deliberately different to the git history,
> and thats a use case that pbr hasn't ever supported (multiple version
> timelines in one git tree). https://review.openstack.org/#/c/162311/
> introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733
> is the bug for this.
Our contrib plugins are not distributed with the heat release and are 
come with a very limited notion of being supported. Operators who want 
to install any are expected to git-clone to the desired revision and 
either cp -r to /usr/lib/heat (our original plugin mechanism) or 
pip-install (so the plugin can be picked up by stevedore).

Specifying the version in setup.cfg was added to stop pbr complaining 
about the lack of version, and to give operators some way of managing 
what version of what they have installed.

We would prefer to keep the contrib plugins in-tree since it lets us run 
their unit tests in the standard gate job, and allows them to evolve 
with internal API additions. I fully realize that having mini packages 
in sub-directories is ... unique.

What I think I would like is a way to tell pbr to ignore git and take 
the overridden version from setup.cfg. Having declarative setup is nice, 
but another option would be to just switch to plain setuptools - these 
are not complicated packages.



More information about the OpenStack-dev mailing list