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 Stefan and others,


I think Pedro's argument sound quite convincing, so maybe I was to quick with my support.


Stefan, what would be your counter arguments?


Kind regards, Ronald


On 06-05-2025 16:22, Pedro M. Baeza wrote:
Although you can think at the beginning that there's no problem keeping the previous migration scripts on each version, there are tons of reasons for not doing it. First of all, it creates on people seeing that migration scripts the false sensation that they don't have to look in any other place for migrating between several versions except on the latest one, while there can happen a lot of things:

- At the moment you are rescuing the commit history to make the migration, the migration scripts for the previous version may still not be developed/merged, and they are incorporated later, so the latest version won't have these migration scripts while they are needed. And you can't demand "openupgraders" to do forward-ports of the migration scripts to each upper version.
- The initial migration scripts may be incorrect or incomplete, and there can be several patches later after upper versions were be ing fetched and migrated. This is even worse IMO, as you think you have the right migration scripts, while they are not the good ones. And again you can't demand the contributors to duplicate the work propagating the patch on the migration scripts (or well, being dreamer thinking that people are going to do it if you state that in the guidelines).

That's why the saner option is to purge these migration scripts from upper versions to only have one source of truth, and this is independent of the type of migration scripts. Stefan states "if they are safe for inclusion in the later version", but that's something very difficult to be judged, specially for the migrators/reviewers which are not used to these migration scripts, so another reason for not having grey areas: you follow the same rule of not having them, as in the end, you have to check the same if they are outdated or missing, etc, etc.

If you do enterprise migrations jumping several versions, you should develop a tool to gather all the migration scripts from the intermediate versions and collect them together. Such tools may be shared and developed collaboratively for those interested. Anyway, take into account that there are a lot of reasons for these migration scripts (being gathered by the tool or being preserved through versions) to fail:

- They expect a specific data model state, based on the version. For example, you may have a migration script that is expecting a column that is declared in version 15, but later in 16, it disappears. If you migrate from 14 to 16, and you run that 15.0 script after having the enterprise migration done up to 16, and with the 16.0 OCA module, it will fail.
- They are also based on the stage of the update process (you have pre, post and end migration scripts). If you execute for example a pre-migration script renaming/creating a column in that phase, and it's already created due to regular update, it will crash. Some said in the past to put protections ("if" sentences checking if the column exists, and so on), but apart from over-complicating the code of migration scripts (and again, you can't demand openupgraders to do or review that job - and imagine if you have to spread it across all versions... -), it doesn't guarantee that the data will be consistent, as there can be a lot of combinations, as much as the source and target version combinations.
- Enterprise migration scripts "clean" the obsolete columns, tables, etc, making sometimes impossible t o rebuild your connections for extra data, links, etc. OpenUpgrade/OCA migration scripts count with the obsolete columns/tables are still there for doing SQLs and other actions, so another possible reason to fail.
- A variant of the previous point: some scripts are developed counting with some specific columns created on the fly or renamed for doing the actions. Example: on the 13.0 migration, we created the columns old_invoice_id in account.move and old_invoice_line_id in account.move.line to point to the old account.invoice and account.invoice.line records, and most of the OCA modules adding fields on the invoice, require these fields for transferring data from one model to the other: https://github.com/OCA/bank-payment/blob/340e44234a165769115bc954120bfcde5dd7b 74e/account_payment_partner/migrations/13.0.1.0.0/post-migration.py#L15

So, in summary, IMO, Odoo enterprise migration service should only be used if you don't have any extra modules in your DB. Once you are using OCA modules, go OpenUpgrade way, or you will spend more time reviewing all of these corner cases than doing it with OpenUpgrade. And if you are not happy with the availability date for OpenUpgrade new versions, help funding its development.

Regards.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Ronald Portier - 05:46 - 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

    23 replies 23 replies

    • Re: Removal of migration scripts on each new version

      Hi, although at first I thought it was a good idea to keep the migration scripts, I now believe there are stronger reasons not to.

      Recently, I was working on a migration from version 12 to 16 of an Odoo Enterprise database with a significant number of OCA modules.

      I’ve built a small script that collects all the relevant migration scripts based on a CSV file specifying the installed modules and the URL of the corresponding OCA repositories:
      👉 https://github.com/javierjcf/odoo-mig-analyzer

      The script is just an initial idea — it takes the list of installed modules from a CSV and generates .txt and .csv files grouped by repository, listing the modules that contain migrations. It can also save these into a directory, which makes analysis easier. However, it’s still necessary to manually build a script that performs the specific migration actions you need from each of them.

      The idea is to take the migrated database returned by Odoo, then run a script in odoo shell that executes the necessary migration scripts for your project. After that, you perform an update all to trigger the final version’s migrations, ensuring all prior scripts were executed.

      The problem: When trying to launch odoo shell, you often encounter errors that require running a first update all, which upgrades the OCA modules to version 16—potentially skipping or breaking some migration scripts that should have run earlier. Also, some scripts may rely on code from the original version, making them incompatible at this stage.

      At this point, the process seems too unreliable. One workaround I considered was running everything directly in SQL, but that could become quite complex depending on the module.

      Right now, I think it’s more practical to use OpenUpgrade to migrate the Enterprise database. Then, manually write scripts to handle the Enterprise modules in use—at least in our case, OCA modules far outnumber the Enterprise ones.

      There really doesn’t seem to be a reliable migration process for Enterprise databases with many OCA modules. The fact that you can’t reliably run all the migration scripts at the correct version steps makes the entire process fragile.

      Does anyone have any ideas on how to make this process more reliable?


      El mié, 7 may 2025 a las 15:53, Richard deMeester (<notifications@odoo-community.org>) escribió:

      Hmm,

      I would argue the opposite.  It is rare that a migration is dangerous to leave in.  If a cetain feature is deprectated in the future that makes the migration irrelevant or wrong, then it needs to be adjusted or taken out.

      But if something needs to be populated if going from 16.0.0 -> 16.0.1, then by extension, it is almost certainly needed if going from 14 -> 18....

      I think part of making changes and adding features is writing relevant migrations, and checking that other migrations are still relevant.

      Kind regards,
      Richard deMeester
      Development QA
      WilldooIT website
      Facebook
      LinkedIn
      PNORS website
      Pacific Commerce website
      WilldooIT website
      Netway Networks website
      WilldooIT is a member of the PNORS Technology Group.
      This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by PNORS Technology Group Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of PNORS Technology Group Pty Ltd or any of its related entities.
          
      From: Enric Tobella Alomar <notifications@odoo-community.org>
      Sent: Wednesday, 7 May 2025 8:52 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Removal of migration scripts on each new version
       
      I prefer to remove the scripts.

      The reason is simple, it is safer. 

      Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.

      We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.

      I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.

      Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)

      My 2 cents.

      El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      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
      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe



      --
      Enric Tobella Alomar
      CEO & Founder

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      by Javier Colmenero Fernández - 04:46 - 7 May 2025
    • Re: Removal of migration scripts on each new version

      Hmm,

      I would argue the opposite.  It is rare that a migration is dangerous to leave in.  If a cetain feature is deprectated in the future that makes the migration irrelevant or wrong, then it needs to be adjusted or taken out.

      But if something needs to be populated if going from 16.0.0 -> 16.0.1, then by extension, it is almost certainly needed if going from 14 -> 18....

      I think part of making changes and adding features is writing relevant migrations, and checking that other migrations are still relevant.

      Kind regards,
      Richard deMeester
      Development QA
      WilldooIT website
      Facebook
      LinkedIn
      PNORS website
      Pacific Commerce website
      WilldooIT website
      Netway Networks website
      WilldooIT is a member of the PNORS Technology Group.
      This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by PNORS Technology Group Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of PNORS Technology Group Pty Ltd or any of its related entities.
          
      From: Enric Tobella Alomar <notifications@odoo-community.org>
      Sent: Wednesday, 7 May 2025 8:52 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Removal of migration scripts on each new version
       
      I prefer to remove the scripts.

      The reason is simple, it is safer. 

      Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.

      We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.

      I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.

      Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)

      My 2 cents.

      El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      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
      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe



      --
      Enric Tobella Alomar
      CEO & Founder

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      by "Richard deMeester" <richard.demeester@willdooit.com> - 03:51 - 7 May 2025

      12 attachments 12 attachments

      image221226.png
      image948425.png
      image699922.png
      image361297.png
      image880946.png
      image764316.png
      image090265.png
      image843456.png
      image767652.png
      image615154.png
      image740632.png
      image245587.png
    • 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
    • Re: Removal of migration scripts on each new version
      I prefer to remove the scripts.

      The reason is simple, it is safer. 

      Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.

      We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.

      I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.

      Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)

      My 2 cents.

      El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      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

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe



      --
      Enric Tobella Alomar
      CEO & Founder

      by Enric Tobella Alomar - 12:51 - 7 May 2025
    • Re: Removal of migration scripts on each new version

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      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

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/
      by Sébastien Alix - 12:26 - 7 May 2025