<div dir="ltr">django_openstack_auth is a library solely consumed by Horizon in OpenStack. We've run into a potential requirements.txt issue. <div><br></div><div>Horizon recently added support for Django 1.7 (1.8 released in the last week, but let's ignore that). The reasoning was that Django 1.6 the previous cap is no longer supported by Django at all, even for security fixes. After adding support, the global-requirements were updated [1] to support an upper end cap of Django 1.7. All is good. Or maybe not.</div><div><br></div><div>So the global requirement and horizon repos now match:</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:11.9999990463257px;line-height:18.6666660308838px;white-space:pre">Django>=1.4.2,<1.8</span><br></div><div><br></div><div>The current released version of django_openstack_auth is 1.1.9. And the requirements.txt for that version states </div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:11.9999990463257px;line-height:18.6666660308838px;white-space:pre">Django>=1.4.2,<1.7</span></div><div><br></div><div>The worry that arose is what dependency problems does this raise for deployers and distros? The 1.1.9 released version of django_openstack_auth code actually supports Django 1.7 even though the requirements don't include that version. But dependency negotiation may result in only 1.6 being used.</div><div><br></div><div>So we have a couple of options. First, leave django_openstack_auth at 1.1.9 and let deployers and distros rationalize which version of Django they want to use and negotiate the dependency issues independently. Or second, release a new version of django_openstack_auth and determine if we want to fix the version django_openstack_auth in global-requirements.txt or leave the upper cap unbound.</div><div><br></div><div>Given the late stage of the release I'm reluctant to release, but would like to better understand the downstream implications of not doing so.</div><div><br></div><div>David </div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/155353/">https://review.openstack.org/#/c/155353/</a></div></div>