Open Stack

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



-- 
Davanum Srinivas :: https://twitter.com/dims