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
Therp, Tom Blauwendraat
- 06/05/2025 23:21:00


On 5/6/25 20:37, Pedro M. Baeza wrote:
[Stefan wrote] >  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.

So I think Pedro and Stefan both have a point:

- Stefan is correct in saying that in some cases, maybe even in most cases, having the migration script there will do the right thing for odoo.sh migrations that skip versions

- Pedro is correct in saying that if we leave the migration script there, we'll have multiple versions of truth for the lower-version migration scripts, and even if it's the latest version it might still fail for all kinds of reasons

From our own experience at Therp, there is currently no "correct" way of doing multiple-versions-Enterprise-migrations with OCA modules. So we do a variety of things:

a) sometimes we deinstall the OCA module and install it back again

b) sometimes we just browse through the previous-version migration scripts of the OCA modules, and chuck excerpts of them in a custom post-migration script

c) sometimes we opt for openupgrade instead, for the reasons Pedro mentioned

d) we also tried to make a framework to go version-by-version and run each enterprise migration version by version, then downloading the db again, running OCA migrations, reuploading etc. But this is very slow, and also Odoo does not allow unsupported versions as a target version, so also not a silver bullet

I'm leaning towards Pedro on this one, because in the case that Stefan describes "for projects where there isn't that much in-depth knowledge (...) on odoo.sh" while we assume that we could help these poor consultants with less knowledge by having the migration script there, it could also well be that:

- we actually introduce new errors for them

- they opt for the hack and slash method anyway eg deinstall and install again

- they edit the module in-place for the time being and copypaste some parts of the older migration script

- they live with the incorrect datamigration, or they fix it in a manual way by exporting/reimporting data from a spreadsheet

- they decide to hire tech-savvy guys to get the oca module and perhaps some of the other breaking things over the line

etc. So while we think we may be helping them, to me it's just an assumption, which is a pretty thin argument to make a change. If it does make things messier for tech-savvy people, then not doing it may be the best option.

-Tom

Reference