#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):
@carljm The thing is that isn't "later" when you remove the migration -
you have to remove it *now* to make any progress. At the point where
people realise the breakage (in this case, when they upgrade to 1.9 and
the migrations stop working), it requires two releases to fix the problem.
This means that I can't do a new release of my package featuring "Django
1.9" support. I have to first tell people "Upgrade to version X-1 of the
library, run migrate, then upgrade to version X". i.e. I have to do a
release just for the migration squashing, and people have to upgrade to
that release as well as the next one.
It is far too optimistic to expect people to migrate away from a field and
to squash their migrations in an earlier release, anticipating the problem
of the field removal, especially when they think they '''have''' already
done that by migrating away from the field. It's also really optimistic to
expect people to read release notes. Only the largest Django libraries
I've used have release notes at all. For most libraries, people expect to
be able to upgrade to the latest version and things will basically work,
after testing and fixing things.
Requiring upgrades to intermediary versions is often problematic,
especially as in this case you actually have to deploy the intermediary
version (in order for the manage.py migrate to get run). Very often you
are going to run into bugs with old versions, which you have to worry
about because you actually have to deploy the code. Requiring upgrades to
intermediary versions '''multiplies''' the amount of work you have to do
to get your dependencies up to date. It's only acceptable for a really
large dependency such as Django itself, where:
* you have an extremely well documented set of release notes,
* that people know about and are expected to read,
* and you also have point releases for the intermediary versions so that
are known 'good' versions you will feel safe deploying.
In short, requiring extra releases just for migrations, and requiring
people to upgrade to all intermediary versions of libraries would be a
really horrible thing for people working in the Django ecosystem, and IMO
the kind of process we should be too embarrassed to document. Certainly it
would introduce a lot of pain into my life, as someone who maintains
several and uses many 3rd party Django libraries.
--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:6>
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.a74f1e5f380ef664de7513f8a8b41df7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
