id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
23861	Fields referenced in migrations cannot be (re)moved, even if migrations have been squashed	Luke Plant	Tim Graham	"Currently `IPAddressField` is set to be removed in Django 1.9.

The problem is that all migrations that use `IPAddressField` will then break, and this means the entire stack of migrations will break (because they are all imported even when not executed, and the migration file references `django.db.models.IPAddressField` at import time). This also means that test suites will break, since migrations are run to set up the DB.

To be clear, this will happen even if you have migrated away from `IPAddressField` - the old versions of the schema still reference `IPAddressField`, and your old migrations will therefore break everything (current migrations, test suite) until they are re-written.

Re-writing old migrations is itself a nasty fix, and not something we want to encourage.

This will be especially bad for 3rd party apps who can't just throw away/squash old migrations. It would be really nasty for users of those libraries if they had to squash all migrations in order to support Django 1.9.

So, I think we need a different strategy for deprecating fields. We need to keep a stub `IPAddressField` around - basically forever.

Also, the deprecation warning for these old fields can make test suite output really noisy if you have warnings turned on (which can be a very good way to find code that needs fixing). Ideally we'd find some way of only outputting the warning when the field was *really* being used - not just instantiated due to an old migration being run.



"	Bug	closed	Migrations	dev	Release blocker	fixed		info+coding@…	Ready for checkin	1	0	0	0	0	0