+1 to call the current master as 1.0 +1 to more frequent releases (not sure if it should be every monday though!)
-- dims On Mon, May 4, 2015 at 3:53 PM, Robert Collins <robe...@robertcollins.net> 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. > > 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 -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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
