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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
