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
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.
by Pedro M. Baeza - 08:35 - 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, removemigrationsfolder 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