Changes between Initial Version and Version 11 of Ticket #23892


Ignore:
Timestamp:
Nov 22, 2014, 11:44:26 PM (10 years ago)
Author:
Carl Meyer
Comment:

Rolled back the kwargs addition, at least for now, since there haven't been any cases presented yet where it would actually offer useful forward-compatibility.

Re-opening and re-purposing this ticket for discussion and documentation of the forwards-compatibility policy for migrations. Markus pointed out in IRC that South effectively maintained forwards-compatibility (that is, generally it was possible to run migrations generated by a later South version on an earlier South version - I'm not sure if this was always true, or just mostly true), so this may be what users expect. I think this may be true, but it doesn't make maintaining forwards-compatibility any more feasible for us. Django migrations, because they make use of a higher-level declarative API in Django (Operations), have much more API surface than South, and most new features / improvements to migrations will require non-forwards-compatible changes to the Operations API (whether that's adding new arguments to existing operations, or new Operation classes altogether).

So I think our choices boil down to "migrations are feature-frozen" or "migrations aren't forwards-compatible." Given those choices, I think the latter is clearly better. A rule that third-party apps should generate their migrations in the oldest version of Django they support is not _that_ onerous or hard to understand.

I'll put together a pull request updating the documentation along those lines. In the meantime, if anyone thinks this is the wrong approach or I've missed something important, please comment!

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #23892

    • Property Owner set to Markus Holtermann
    • Property Triage Stage UnreviewedAccepted
    • Property Has patch set
    • Property Component MigrationsDocumentation
    • Property Summary Make deconstructible classes forwards compatibleClarify forwards-compatibility policy for migrations
  • Ticket #23892 – Description

    initial v11  
     1We need to clarify in the documentation whether or not we are attempting to make migrations forward-compatible (that is, guarantee that it will be possible to run migrations generated on later Django versions under earlier Django versions).
     2
     3Original description:
     4
    15The migration operations don't accept any additional arguments (neither `*args` nor `**kwargs`). This will lead to problems in older (>=1.7) Django versions if the the migration files for 3rd party apps have been created with newer Django versions in case the new operations have a different constructor signature. Thus `**kwargs` should be added to all operation signatures.
    26
Back to Top