Open Stack

Hi, I'd like to talk about how often we can and should release pbr,
and what criteria we should use for 1.0.

tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0
immediately.

pbr, like all our libraries affects everything when its released, but
unlike everything else in oslo, it is an open ended setup_requires
dependency. It's like this because of
https://github.com/pypa/pip/issues/2666 - when setuptools encounters a
setup_requires constraint that conflicts with an already installed
version, it just gives up.

Until thats fixed, if we express pbr constraints like "pbr < 1.0"
we'll cause everything that has previously released to hard-fail to
install as soon as anything in the environment has pulled in a pbr
that doesn't match the constraint. This will get better once we have
pip handle setup_requires with more scaffolding... we can in principle
get to the point where we can version the pbr setup_requires
dependencies. However - thats future, and indefinite at this point.

So, for pbr we need to have wide open constraints in setup_requires,
and it must be in setup_requires (otherwise pip can't build egg info
at all and thus can't probe the install_requires dependencies).

The consequence of this is that pbr has to be ultra conservative -
we're not allowed any deliberate API breaks for the indefinite future,
and even once the tooling supports it we'd have to wait for all the
current releases of things that couldn't be capped to semantic
versioning limits, to be unsupported. So - we're at least 18 months
away from any possible future where API breaks - a 2.0 - are possible
without widespread headaches.

In light of this, I'd like to make two somewhat related proposals.

Firstly, I'd like to just call the current master 1.0: its stable,
we're supporting it, its not going anywhere rash, it has its core
feature set. Those are the characteristics of 1.0 in most projects :).
Its not a big splashy 1.0 but who cares..., and there's more we need,
but thats what 1.x is for.

Secondly, I'd like to release every Monday (assuming no pending
reverts): I'd like to acknowledge the reality that we have
approximately zero real world testing of master - we're heavily
dependent on our functional tests. The only two reasons to wait for
releasing are a) to get more testing, and we don't get that, and b) to
let -core notice mistakes and back things out. Waiting to release once
an improvement is in master just delays giving the benefits to our
users.

-Rob

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