Bugs with no response from Debian maintainer (except #755645 with no recent activity):
[...]
#760875 [i| | ] [src:django-longerusername] django-longerusername: Please fix the package for Django 1.7
Possibly this bug should have gone in a separate section "Bugs in packages that are dead upstream." Not sure.
Not sure that the reason given justifies the bug ("it only provides a south migration") - in general packages seem to work fine in Django1.7 even with only south migrations.
There was another package (python-guardian) that could not be made compatible with Django 1.7 without updating all the migrations - I have a suspicion this might be because the test models are derived from AbstractUser and as such you end up with a guardian app without migrations depending on django app with migrations, which is documented as not being supported in Django docs).
On this note, I believe it is possible (like in South) to insert a migration between two numbered migrations. e.g. lets say we can a Django 1.7 migration:
testapp/migration/0001_initial.py
Then upstream creates a migration 0001_initial.py that is different to the Debian one. Maybe it includes changes that weren't available in the released version at the time.
So the obvious solution for Debian would be to use its 0001_initial migration, ignoring upstream's copy, and create another migration, to update the state to the upstream state:
testapp/migration/0001_initial.py
testapp/migration/0002_fixup.py
However if we do this, we will always be different from upstream, and have to renumber all there subsequent migrations.
As far as I know, we can do this instead:
testapp/migration/0001_initial.py
testapp/migration/0001a_fixup.py
So when upstream releases migration 0002_newfeature there is no conflict, and we get back to using upstream migration numbers. I believe this would work in South, seems to work with Django 1.7 migrations too.