Squash migrations to remove use of index_together

[mschoettle]

Django 5.1 will remove index_together meaning that the migration (0004) making use of it will fail.

This PR squashes all migrations from 0004 to 0019.

Note that the following warning for migration 0013 was emitted:

Functions from the following migrations need manual copying.
Move them and any dependencies into this file, then update the
RunPython operations to refer to the local versions:
easyaudit.migrations.0013_auto_20190723_0126

I removed the drop_index_if_exists since there will only be one index added.

This might be a breaking change so might be necessary to increase the version to v2.

[jheld]

I have done squashes and resetting of migrations in the past, but I don't recall having done it from a library. If it constitutes a breaking change for the user, is there anything we can do to stop them before they deploy/run their app (or in fact, there migrations), as a just in time sanity check? If I get my thoughts more solid on this I'll reply back again with any feedback.

[mschoettle]

Based on the documentation on squashing migrations this seems to be a safe operation.

The interesting parts:

These files are marked to say they replace the previously-squashed migrations, so they can coexist with the old migration files, and Django will intelligently switch between them depending where you are in the history. If you’re still part-way through the set of migrations that you squashed, it will keep using them until it hits the end and then switch to the squashed history, while new installs will use the new squashed migration and skip all the old ones.

This enables you to squash and not mess up systems currently in production that aren’t fully up-to-date yet. The recommended process is to squash, keeping the old files, commit and release, wait until all systems are upgraded with the new release (or if you’re a third-party project, ensure your users upgrade releases in order without skipping any), and then remove the old files, commit and do a second release.

So this will be a multi-step process:

1. Squash migrations and keep the new migration along with the old ones
2. In a future release (after the squashed migration has been released): Remove the old migrations and convert the squashed migration to a normal migration

The only case that can be problem is if users have added a dependency in one of their migrations to a migration of this package. In that case they would need to update that reference.

If it constitutes a breaking change for the user, is there anything we can do to stop them before they deploy/run their app (or in fact, there migrations), as a just in time sanity check?

I'd say like with any other breaking change (or changes in general) too:

• the user needs to read the release notes
• the user should first test this in a non-production environment before deploying it to production