/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