Open Stack

> On Dec 9, 2016, at 4:47 PM, Richard Jones <r1chardj0n3s at gmail.com> wrote:
> 
> Hi folks,
> 
> We in Horizon land are looking to update to a new version of one of
> our dependencies, Angular Bootstrap version 2.2.0. We do this through
> xstatic packaging, so the release we'll be making is actually
> xstatic-angular-bootstrap 2.2.0.0
> 
> This release is backward incompatible and breaks Horizon in many ways.
> We already have a compatibility patch in review to get us up to speed
> in Ocata, but prior versions of Horizon would break without
> upper-constraints protections. We've recently pushed through several
> changes to stable Mitaka to get those protections in place - Newton
> was already protected.
> 
> The problem is that we'll have two Ocata milestone releases out when
> 2.2.0.0 is released, and those will break because we currently pull in
> *master* upper-constraints for the milestone releases, rather than a
> stable/ocata branch of upper-constraints - there is no stable/ocata
> branch of upper-constraints yet.
> 
> Has the idea of branching at development milestones been raised previously?

Hi Richard :)

I'm not sure it has, but I'm rather certain it's not tenable. Now that you bring this up, Horizon isn't the only project that will get bit by this - Glance will too. (Until recently Glance's tests were not happy with the newest version(s) of oslo.log)

I don't think *branching* is the solution here, but perhaps tagging/releasing the requirements repository like we do other projects would be. That said, this introduces a significant amount more work for milestone releases. Here's how I imagine it would have to work:

openstack/requirements enters a freeze period leading up to a milestone. It tags it's Pike-1 milestone. This triggers the Requirements Bot to go around and update the constraints URL to the Pike-1 tag instead of "master". Once those are successfully merged, other projects releasing following the cycle-with-milestones release tag would then be able to create they own Pike-1 tag. After a successful release, cores would have to update their tox.ini files to go back to master's constraints.

(And I'm not entirely certain we could get the proposal bot to ignore us switching constraints URLs back so that part may have to be manual too.)

The root of this discussion, however, seems to be around the idea that there are downstream consumers who are deploying OpenStack without distribution-provided packages (or using a deployment project) and who are using a rather naïve approach to dependency management. This is something that has come up within Glance as well recently (that each milestone needs to have certain restrictions).

Is there good evidence of this behavior anywhere? We've had trouble finding evidence of this happening in the real world with Glance and there's nothing in the project team guide that indicates the same level of support for milestone releases as for cycle releases.

--
Ian