-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu 28 Feb 2013 06:58:36 AM EST, Matthias Runge wrote:
Dear list,
Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages.
The plan is, to delay the push, until other packages are fixed, or to push in about 14 days.
I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18.
http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5...
How many Django-based packages are we talking about? Should we be considering putting things together in a side tag before landing in Rawhide?
Also, I know at least Review Board is incompatible with 1.5 at this time. They're planning to have a 1.5-compatible release sometime in the next month or so.
Looking at the release notes[1], there is a sizeable number of backwards-incompatible changes present in this new version. I think it's going to bite us if we force it straight into Rawhide at this point. Given the way that Django tends to operate (backwards-incompatible releases about every six months with only the current and previous release supported for bugfixes and security), I'm wondering if we shouldn't just drop the 'python-django' package entirely and go with 'python-django14', 'python-django15', etc. from here until eternity, retiring unsupported versions only between upstream releases. This is a policy that would probably also work acceptably for EPEL (CCed).
Also, Django 1.5's release notes[2] indicate that it now has support for Python 3.2 and later. I'd strongly recommend that we should be dual-building python3-django15 as well here.
[1] https://docs.djangoproject.com/en/1.5/releases/1.5/#backwards-incompatible-c... [2] https://docs.djangoproject.com/en/1.5/releases/1.5/#python-3-support
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/28/2013 02:16 PM, Stephen Gallagher wrote:
On Thu 28 Feb 2013 06:58:36 AM EST, Matthias Runge wrote:
Dear list,
Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages.
The plan is, to delay the push, until other packages are fixed, or to push in about 14 days.
I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18.
http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5...
How many Django-based packages are we talking about? Should we be considering putting things together in a side tag before landing in Rawhide?
Well, looking at my list of ~40 python-django packages, I know by coincidence just a single package to be compatible with Django-1.5
Looking at the release notes[1], there is a sizeable number of backwards-incompatible changes present in this new version. I think it's going to bite us if we force it straight into Rawhide at this point. Given the way that Django tends to operate (backwards-incompatible releases about every six months with only the current and previous release supported for bugfixes and security), I'm wondering if we shouldn't just drop the 'python-django' package entirely and go with 'python-django14', 'python-django15', etc. from here until eternity, retiring unsupported versions only between upstream releases. This is a policy that would probably also work acceptably for EPEL (CCed).
That seems to be a good proposal for me. Review request is here[1], based on the current python-django package. Shouldn't be an issue. For EPEL, we have the Django14 package. This shouldn't change there, but we can think about introducing provides: python-django14 there.
Also, IMHO the number of incompatible changes became less and less disruptive in the past, and I see this as maturing of the project.
Also, Django 1.5's release notes[2] indicate that it now has support for Python 3.2 and later. I'd strongly recommend that we should be dual-building python3-django15 as well here.
Yes, I was thinking about a python3-django feature for F20, as it's absolutely too late for this as a feature for F19, right?
As there is at least /usr/bin/django-admin provided by the package, we should decide, if that should be coming from the python3 package, if the python3 version should carry a python3 (or just a 3) in it's name, or what to do else.
Matthias
[1] https://bugzilla.redhat.com/show_bug.cgi?id=916676 - -- Matthias Runge mrunge@matthias-runge.de mrunge@fedoraproject.org
Hi
On Thu, Feb 28, 2013 at 11:13 AM, Matthias Runge wrote:
Yes, I was thinking about a python3-django feature for F20, as it's absolutely too late for this as a feature for F19, right?
I don't think so. Even if you want go through the formal feature process, you can request an exception
Rahul
epel-devel@lists.fedoraproject.org
-
Matthias Runge -
Rahul Sundaram -
Stephen Gallagher