Open Stack

On Mon, May 4, 2015, at 12:53 PM, Robert Collins wrote:
> 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.
Sounds good.
> 
> 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.
I don't understand what you mean by "zero real world testing of master".
We test that pbr can make sdists and install packages on every change to
master before merging those changes. That is the majority of what pbr
does for us. We can definitely add more testing of the other bits
(running tests, building docs, etc), but I don't think it is fair to say
we have approximately zero real world testing of master.

Clark