cubicweb #17254006 Better handling of upgrades scripts [open]

upgrade scripts from cubicweb_<cube>/migration/X.Y.Z_Any.py are executed only if package version is set to a higher or equal version than X.Y.Z

This have some drawbacks:

  • When adding a new migration without increment the version (e.g. default development mode), the migration isn't executed
  • Working with an instance which is continuously deployed require to increment the version number
  • cubicweb_<cube>/migration/ files are subject to conflict when having multiple modification from several mercurial draft heads.

I propose to implement a new algorithm for migration, inspired from django (formely south).

To create a migration, add a new command "makemigration <name>" that create a new unique filename in the migration directory, something like <date>_<name>.py

Add a new sql table containing the name, eventually cube name of the migration that where already executed. When cubicweb starts, it check all available migrations files have been executed, otherwise it fail and suggest to run "cubicweb-ctl upgrade"

cubicweb-ctl upgrade execute migrations files in the correct order.

priorityimportant
typeenhancement
done in<not specified>
closed by<not specified>