Open Stack

> > /requirements hat
> >
> > l-c was mainly promoted as a way to know when you are using a feature
> > that is not in an old release.  The way we generally test is with newer
> > constraints, which don't test what we state we support (the range
> > between the lower bound in requirements.txt and upper-contraints).
> >
> > While I do think it's useful to know that the range of versions of a
> > library needs to be updated... I understand that it may not be useful,
> > either because of the possible maintenance required by devs, the load on
> > the testing infrastructure generated by testing lower-constraints or
> > that downstream packagers do not use it.
> >
> > Search this for lower-constraints.
> > https://docs.openstack.org/project-team-guide/dependency-management.html
>
> I am in the same boat as Brian that the lower-constraints have never made
> much sense to me.  The documentation you share above is helpful to
> understand how everything works but I think it maybe needs to be enhanced as
> it isn't clear to me as a Cinder team member what I should do to avoid
> breakages.
>
> If we can add some documentation and guidance as to how to maintain these in
> the branches to avoid a major breakage like this in the future I think it
> would be a useful effort.
>
> Jay
>

I agree documentation could really be improved here. But one thing to keep in
mind that I think is worth pointing out is that the current breakages are
really due to enhancements in pip.

Our l-c jobs have been broken for a long time, and we are now just being made
painfully aware of it. But now that pip actually enforces these things,
theoretically at least, once we fix the problems we have in l-c it should be
much easier to maintain going forward. We shouldn't have random stable branch
failures, because once we fix our requirements they should remain stable going
forward.

// 2 cents