Order in django migrations
<p>we are working on a web application that has one central app, and a new one we added lastly.</p>

<p>The migrations order is the following:</p>

<pre><code>contenttypes 0001 
contenttypes 0002

auth         0001
...
auth         0006

main_app     0001
...
main_app     0045
</code></pre>

<p>After adding the new app, the migration's order was the following:</p>

<pre><code>contenttypes 0001
auth         0001
main_app     0001
...
main_app     0045
contenttypes 0002
auth         0002
...
auth         0006
new_app      0001
</code></pre>

<p>There are few things worth to note:</p>

<ol>
<li><p><code>new_app.0001</code> migration has the dependencies (in this order):</p>

<pre><code>auth.0006
main_app.0045
</code></pre>

<p>And only create a foreign key to user.</p></li>
<li><p><code>auth.0004</code> migration update the username to have a max length of 30</p></li>
<li><p><code>my_app.0012</code> udpate the <code>user.username</code> field to have a length of 255 (through some <code>AlterField</code>-derived class)</p></li>
</ol>

<p>So because of the order in which the migration are ran, without the <code>new_app</code>, the resulting <code>user.username</code> length is 30 instead of 255.</p>

<p>In the initial <code>my_app</code> migration, we have the following dependency: </p>

<pre><code>migrations.swappable_dependency(settings.AUTH_USER_MODEL)
</code></pre>

<p>(which seems to be required when you change the default django user model).</p>

<p><strong>The questions are:</strong>
Why is the order of the migration changes ? How to prevent it ? </p>

<p><strong>Note:</strong> we did found a "hacky" way to prevent this, by adding a dependency in the <code>my_app</code> initial migration:</p>

<pre><code>migrations.swappable_dependency(settings.AUTH_USER_MODEL),
auth.0006
</code></pre>

<p>But we do not think this is a viable solution, so we are looking for a better one.</p>