Re: Problem migrating from South to Django migrations for Linux distributions

So, South migrations will not work with Django 1.7. Period.

There is no way around this; it's unfortunate that the packaging situation means that Django will get auto-upgraded as part of a distribution upgrade; I'm surprised that Debian hasn't had this with packages before? (Version upgrades that break installed but non-packaged things)

Neither of your suggested ways to go forward will work; the two history models are very different, so the tagging of positions isn't going to work, and Django 1.7 has changed substantially enough internally that porting South 1.x up to it would be a very large amount of work.

How has Debian dealt with breaking changes like this in the past? Things like Rails upgrades come to mind. This change isn't as bad - nothing will actually _break_ when you upgrade, and apps will still run, but migrate will instead fall back to non-migration mode (which won't destroy any tables, but will fail to apply any table alterations).

Also, what are the applications in particular that this will be a problem for? I'm curious to know what Django + South things Debian is shipping these days.

Andrew

On Thu, Jul 24, 2014 at 1:27 PM, Raphael Hertzog <raphael@ouaza.com> wrote:

[ Please keep me in CC ]

Hello,

I'm one of the python-django Debian package maintainers and I have been
working on preparing the field for Django 1.7... and we have one problem
that we don't know how to handle.

Consider that Debian contains Django but also Django applications using
South. When our users will upgrade from Debian 7 to Debian 8
they will upgrade at the same time Django itself and the Django applications.

The new versions of the Django applications are likely to have unapplied
schema migrations managed by South but the system will have Django 1.7
and we have no means to let the users apply those schema changes.

I see two ways to go forward:
- either we find a way to apply South migrations with Django 1.7
- or we enhance Django migrations to be able to tag some point
in the Django migrations as equivalent to some other point in the
South migrations, that way we can recreate the supposedly-unapplied
South migrations with Django 1.7 and mark those as unneeded if all
South migrations were already applied

How can we solve this problem?

Thank you for your help!
--
Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/