Re: [openstack-dev] [Horizon] [all] django_openstack_auth potential release

2015-04-09 Thread Thierry Carrez
David Lyle wrote:
 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.

I pinged packagers to get their feel on the issue.

It's sad that we have to do this at this point, but I feel like bumping
to 1.2.0 with the correct cap is the right solution here.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Horizon] [all] django_openstack_auth potential release

2015-04-08 Thread David Lyle
django_openstack_auth is a library solely consumed by Horizon in OpenStack.
We've run into a potential requirements.txt issue.

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.

So the global requirement and horizon repos now match:

Django=1.4.2,1.8

The current released version of django_openstack_auth is 1.1.9. And the
requirements.txt for that version states

Django=1.4.2,1.7

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.

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.

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.

David

[1] https://review.openstack.org/#/c/155353/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon] [all] django_openstack_auth potential release

2015-04-08 Thread Akihiro Motoki
2015-04-09 6:32 GMT+09:00 David Lyle dkly...@gmail.com:
 django_openstack_auth is a library solely consumed by Horizon in OpenStack.
 We've run into a potential requirements.txt issue.

 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.

 So the global requirement and horizon repos now match:

 Django=1.4.2,1.8

 The current released version of django_openstack_auth is 1.1.9. And the
 requirements.txt for that version states

 Django=1.4.2,1.7

 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.

 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.

At least the upstream released version should provide the correct
requirements files
so that Django 1.7 is installed, so I think the first option may bring
confusion.

 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.

I prefer the second option to release a new version of
django-openstack-auth for Kilo (with Django 1.7 support)
because some features of Kilo Horizon require a new version of
django-openstack-auth.
The new version will be 1.2.0 as it has new features with keeping the
backward compatibility.
It sounds reasonable to me that Kilo Horizon requires:

django-openstack-auth=1.2.0,1.3.0.

For Juno release, both Horizon and django-openstack-auth 1.1.9 or
older version requires Django 1.7.
Both use the same version and it looks good.

I believe this makes the situation simple.


The third option is to change only requirements file to Django1.8 and
release django-openstack-auth 1.1.10, but it will be a bit difficult because
we need to cut a branch for kilo first.

Akihiro


 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.

 David

 [1] https://review.openstack.org/#/c/155353/

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Akihiro Motoki amot...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev