Hey everyone,

The os-ansible-deployment team was working on updates to add support for
the latest version of juno and noticed some interesting version specifiers
introduced into global-requirements.txt in January. It introduced some
version specifiers that seem a bit impossible like the one for requests
[1]. There are others that equate presently to pinning the versions of the
packages [2, 3, 4].

I understand fully and support the commit because of how it improves
pretty much everyone’s quality of life (no fires to put out in the middle
of the night on the weekend). I’m also aware that a lot of the downstream
redistributors tend to work from global-requirements.txt when determining
what to package/support.

It seems to me like there’s room to clean up some of these requirements to
make them far more explicit and less misleading to the human eye (even
though tooling like pip can easily parse/understand these).

I also understand that stable-maint may want to occasionally bump the caps
to see if newer versions will not break everything, so what is the right
way forward? What is the best way to both maintain a stable branch with
known working dependencies while helping out those who do so much work for
us (downstream and stable-maint) and not permanently pinning to certain
working versions?

I’ve CC’d -operators too since I think their input will be invaluable on
this as well (since I doubt everyone is using distro packages and some may
be doing source-based installations).



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to