Open Stack

On 05/04/2015 03: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.

WFM

> 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'm fine with that in principle - I tend to release personal libraries
pretty much as soon as something interesting hits them. I have no
personal fear of high release counts.

I'm not sure I 100% agree with "every Monday" ... I think we should be
flexible enough at this point to just release actively. But I don't feel
strongly about it.

Monty