Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Removal of migration scripts on each new version

Archives

Contributors

Re: Removal of migration scripts on each new version

Re: Removal of migration scripts on each new version

Re: Removal of migration scripts on each new version


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

by Tom Blauwendraat - 11:26 - 6 May 2025

Reference

  • Removal of migration scripts on each new version
    Hi,

    the migration guide mandates the following

    > Remove any possible migration script from previous version (in a nutshell, remove migrations folder inside the module if exists).

    (https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)

    However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.

    I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.

    My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).

    Can I have a temperature check from the community to see how you all feel about this?

    Best regards,
    Stefan

    -- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail: stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web: https://opener.amsterdam
    by Stefan Rijnhart - 01:00 - 6 May 2025