On 02/05/15 07:06, Robert Collins wrote:
On 2 May 2015 at 04:17, Doug Hellmann <[email protected]> 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.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to