1. Mailing Lists
  2. Contributors
  3. Re: Removal of migration scripts on each new version

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Removal of migration scripts on each new version

Re: Removal of migration scripts on each new version

Avatar

Re: Removal of migration scripts on each new version

by
Tecnativa. S. L., Pedro M. Baeza
- 06/05/2025 20:33:26
Stefan, all your suggestions seem to overcomplicate the general management of the migrations, although you say it doesn't mean anything for openupgraders. If we allow this, pull requests will be filled by petitions around migration scripts. You should consider the creation of such a tool that gathers the corresponding migration scripts across versions. That is IMO the definitive way of dealing with this, as if not having half migration scripts is not the solution, as in the end, the migration is incorrect. And worst, the missing bits may pass unnoticed. Not having anything migrated leads to checking what's going on and then doing it the right way.

>  True. Maybe a saner option would be to just always keep them, for say three versions (matching Odoo version lifecycle, c.q. maximum upgrade cycle).

With this, OCA issue trackers will be full of issues saying that the module X breaks their Odoo.sh build/test/migration, due to the already explained reasons to fail.

> Well, even handling such a tool is a lot of effort, requiring at least a fork of all the OCA projects

This can be done through GitHub API (check for example some API and file manipulation in https://github.com/OCA/maintainer-tools/blob/master/tools/migrate_branch_empty.py), but I agree it requires some effort.

> Instead, by keeping the migration scripts for a number of versions, we can make life easier for projects where there isn't that much in-depth knowledge.

I insist that this won't be true a lot of times due to crashes or half-baked data that seems to be OK, but they are not. I have rescued several projects from others with not "much in-depth knowledge", and it's a hell to straighten the instance. I can't imagine what would be to deal with inconsistent DBs due to this...

> It sounds like you are defending the policy so as to discourage the use of the enterprise migration service.

Well, I put "IMO" on purpose to say that it's my opinion, but it's an opinion consolidated across multiple attempts of using enterprise migration service with a lot of pain. That's why I recommend using it only if you don't use anything extra, as if not, the time spent getting a functional migration is higher than using OpenUpgrade (this once you get over the initial entry barrier).

Regards.

Reference