Just to be absolutely clear: Fedora 21 would continue to ship Django 1.6 as well, using the traditional python-django16 compatibility package?

Thus, the scope of this change would be:
1. Package Django 1.7 as python-django
1. Package Django 1.6 as python-django16
1. Ensure that any existing packages in Fedora that can use Django 1.7 do so and that packages that are not ready are adjusted to work with the compatibility package

Does that fairly cover the situation?

If so, I am +1 to this late proposal, on the grounds that none of the packages in question have any impact on the release date and as long as the first two pieces are done in time for Final release, the dependent packages can be fixed with updates if necessary.

I would try to avoid to continue to ship Django 1.6. In the past, with parallel installable versions, this caused more confusion than it helped.

Now for the upgrade form Django-1.6 to Django-1.7, changes were rather small or even not existent.
E.g for OpenStack Horizon, there was a change necessary for the wsgi file. It turned out, that could have been changed a long time ago, and it even works with Django-1.4:

https://docs.djangoproject.com/en/1.7/releases/1.7/#wsgi-scripts

When upstreams provide a wsgi file, they should be pretty acceptive for such a patch.

Simply put, I'd be -1 to shipping ONLY 1.7 in Fedora 21. It would break existing software. Because of Django changing compatibility with every release, a lot of software explicitly refuses to run on newer versions until upstream gets around to certifying it.

Also, as we've previously discussed, it makes sense for Fedora to carry both supported upstream versions in the release. If 1.8 was just about to land, that might be a different story, since we'd not be able to maintain 1.6 soon.

Also, I have a project (Review Board) that explicitly doesn't support 1.7 yet. Speaking entirely as the maintainer of that package, I'd be opposed to shipping only 1.7 this late.

So if you want to ship both 1.6 and 1.7, I'm in favor. If you only want to ship one, it should be 1.6 (but it would be unfortunate not to have both).

I'm +1 to shipping just 1.7, because of the March 2015 EOL issue. We can advise people who need 1.6 to stick with F20 until they can migrate. (F20 will be supported past March 2015 too, but not much we can do about that.)

Matthias, can you come to the FESCo meeting on Wednesday if we discuss this more and vote on it?

Matt, yes, I probably can attend.

Can we get a sense of the number of packages in Fedora which are not ready for 1.7?

I won't be at the meeting tomorrow, but I guess I am with sgallagh: Either ship both, or just 1.6. Forcing a 1.7 change at this point in the cycle seems a bit rushed.

Replying to [comment:8 mattdm]:

Can we get a sense of the number of packages in Fedora which are not ready for 1.7?

All packages required to run OpenStack Dashboard are ready for Django-1.7 (in Juno and Icehouse version).

I can't say, if reviewboard is really not ready, because it other requirememts are a bit special (required versions not in fedora, some newer, some older).

We have currently 86 packages requiring python-django in total, including eclipse-pydev and python-django-doc.

7 packages are known to be broken already in f21, see branched report.

6 packages are known to work, python-django-south is integrated in Django-1.7

Replying to [comment:9 kevin]:

..., but I guess I am with sgallagh: Either ship both, or just 1.6. Forcing a 1.7 change at this point in the cycle seems a bit rushed.

I might not be able to attend, too. But I'm also +1 for sgallagh proposal. I think we should bot be doing such a change so late in the release process.

Just to note, if we want Django 1.7 in F21, it must be in the Beta. So we will need a Freeze Exception and a build tonight if that is the case.

I can state for the record that Django 1.7 does not work with django_evolution, which is an alternative to django_south that several packages (including Review Board) rely upon.

I know of several deployments using F21 pre-release already for Review Board; I'd be very disappointed if we broke them.

Frankly, my ideal approach would be:
* Ship Django 1.7 as python-django
* Ship Django 1.6 as python-django16 in the parallel-installable mode

I'm curious why you said above "In the past, with parallel installable versions, this caused more confusion than it helped." I didn't see that as being a major issue. However, if you have strong data behind this, I'd be alright with a Conflicts: between 1.6 and 1.7 as long as both are available in the distro. (Though obviously I much prefer the parallel-installation)

My main concern: What's the plan for what to do with a serious vulnerability in 1.6 past its EOL but within the F21 lifetime? If the plan is "hope that doesn't happen", at least we'll know that in advance. Or, would we be committing to backporting patches?

IIRC, the historic approach has been to work with dependent packages to get them to work on the newer supported versions of Django where possible and otherwise just accept that once it's EOL, all bets are off.

Replying to [comment:13 sgallagh]:

I'm curious why you said above "In the past, with parallel installable versions, this caused more confusion than it helped." I didn't see that as being a major issue. However, if you have strong data behind this, I'd be alright with a Conflicts: between 1.6 and 1.7 as long as both are available in the distro. (Though obviously I much prefer the parallel-installation)

I received at least 2 bug reports via bugzilla and 1 or two personal mails, because people expected the parallel installable version to work exactly as the most recent version (i.e. no modification in code).

• AGREED: no exception for 1.7; will stick to 1.6 (since fedora 22 release scheduled to be proper 6-month cycles) (no vote, just general agreement)
• a copr could address 1.7 for people who need it (and there is one -- https://copr.fedoraproject.org/coprs/mrunge/django-1.7/ )