More efficiant migration management

[francois90]

This idea may be bad for reasons that i am not seeing, but it seems to me like it would be possible to have two types of migrations, the ones that are committed and the ones that aren't. This way, it would be possible to have a deployment script that deletes all uncommitted migrations, runs makemigrations in order to recreate them in one batch, commit the newly created migrations and deploy. This would have the benefit of keeping everyone on the same page regarding migrations that are in production while reducing the number of migrations and minimizing the chances of conflicts.

The way i envision implementing this is by simply giving a different name to uncommitted migrations so they can be put in .gitignore. It could be done by adding a setting for configuring a custom string to add at the end of newly created migrations.

Please anyone let me know if this is a bad idea or if there is a better way to implement it.

Cheers

[Mariusz Felisiak]

Thanks for this proposition, however I don't see why you need a special built-in workflow to do this. makemigrations already supports the --name option, so you can name uncommitted migrations in a different way and do this exactly as described. Most of this flow is outside of Django. I don't see a reason to add a new option and especially encourage it.