#23861: IPAddressField removal will break migrations and test suites
-----------------------------+--------------------------------------
Reporter: spookylukey | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------------------------
Comment (by spookylukey):
I agree that removal of fields is not very common. But that is kind of
irrelevant - because we '''are''' removing a field '''now''', and there
are likely thousands of projects that use `IPAddressField` -
https://github.com/search?l=&q=IPAddressField+extension%3A.py&ref=advsearch&type=Code&utf8=%E2%9C%93
I don't think this is 'no different' to other deprecations, because you
can't immediately go and fix the code that is causing the warning (which
is itself an issue - warnings that you cannot do anything about are worse
than nothing, because they drown out other warnings that are important.
This is currently an issue for me as I try to get a test suite to run
without warnings - removing the offending migrations is probably not going
to be possible for a long time). You can't just remove the code - you have
to plan the removal of the old migrations into a release process. And you
have to do so while thinking about all the Django versions that you are
still supporting.
Regarding your solution, I had the same idea above, but I think it does
improve the situation drastically - it means that you now have an upgrade
procedure for libraries that doesn't involve multiple releases:
If I want version 3.0 of my foobar library to support Django 1.9, I can
just add the following to upgrade notes:
* You will need to upgrade to foobar 3.0 and run migrations before you
upgrade to Django 1.9, due to a removed field in Django 1.9
You simply have to ship 3.0 with squashed migrations that don't reference
the removed field. If people fail to follow that instruction, they'll get
a clear error which will stop the migration, and which can be fixed by
downgrading to pre-1.9. The old migration files can be kept around until
version 4.0 if you have to, as they don't bother anyone, which means you
can keep them in the 'master' branch on GitHub or wherever. So people will
still be able to upgrade to your latest version, provided they do so
before upgrading Django.
This upgrade process fits into a normal upgrade/deploy procedure, which
typically runs something like this when automated:
* update sources
* pip install -r requirements.txt
* ./manage.py migrate
So there is no need to do any manual deploy etc.
The only extra burden is that you are forcing users to stagger the
upgrades of dependencies, but it is quite likely that you would do that
anyway (in order to check if some upgrade has broken something).
There is no installing of intermediate versions, and no testing of them,
only to find bugs that don't exist in the latest version etc. It is this
problem that is the real killer for me - if I have to install older
versions, test and deploy etc., that is going to add hours of work.
Multiply that across thousands of projects, and I think there is case for
making this significantly less painful than it is at the moment. I
appreciate that there is potentially some significant complexity involved
of course.
--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.5a1f39554a125187e0d2724ded222c1e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
