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 

Hi everybody,

thank you for your input. Some good points have been raised indeed not 
to keep the scripts by default:

* By assuming that keeping the migration script helps people, we might 
underestimate the ability of developers and consultants to recover from 
their absence. In this light, arguably, breaking a migration process 
with an invalid migration script might make things worse than having no 
migration at all, at least for non-developers.
* While in my experience migration scripts are testable, such tests are 
rare and may not be worthwhile and as such the untested migration 
scripts will lack the quality assurance that is the OCA seal.
* As a party that does a lot of migrations in the way that would 
potentially benefit by keeping the scripts, C2C has indicated that they 
prefer to use a bespoke selection of scripts.

I have also been browsing the migration scripts in 15.0, 16.0 and 17.0. 
On average, 5% of all modules have a migration script for the current 
version. For sure there are some scripts that are going to cause issues 
in later versions (scripts that update translatable fields using SQL 
before the translation refactoring, or scripts that query ir.property). 
At the same time, there are lots of scripts that are unproblematic for 
the next version. Most scripts are short and easy to review.

So I would still be interested to pursue a more pragmatic approach for 
this on the project/module/maintainer level, as Stéphane suggests below 
(and Sebasien Alix also hinted at). So that when we maintain, migrate, 
or review a module we can put in the extra effort to vouch for an older 
migration script to work on the next version. The policy would then 
still be to drop the scripts by default. Would that be something we can 
settle on?

On 07-05-2025 12:12, Stéphane Bidoul wrote:

> As a maintainer I would like to have the liberty of keeping the 

> migration scripts if I want to, as I think it is a good service to 

> provide to my users.

>

> In the modules I help maintaining it is usually not a problem nor 

> difficulty. For instance in mis_builder and queue_job It's likely that 

> we could have all the scripts for the past 8 versions run on the latest.

>

> So I don't quite understand why it is forbidden to keep them. If I 

> want to take responsibility for maintaining them I should be allowed 

> to do so.

>

> Best regards,

>

> -Stéphane


-- 
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 - 03:48 - 7 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