[16.0] odoo_repository_migration: qualify a module as renamed or replaced starting from next Odoo version

[sebalix]

On a module branch form, managers are able to qualify the current module with 3 options regarding the next Odoo version:

• unchanged/named the same: default value, meaning the the module name didn't changed from current version to next one
• renamed to: the module has been renamed, it still has its previous commits history allowing a comparaison of commits (migration scan)
• replaced by: the module has been replaced by another one, could be by a std Odoo module, or any module that doesn't share the same commits history. Migration status for such modules will be set to "Replaced".

(stock_packaging_calculator has been renamed product_packaging_calculator, but I set it with "replaced by" flag only for test purpose here)

Example of a project CSV migration export (here a renamed module):

For renamed modules, the migration scan is then working with this ongoing development:

• [IMP] Add support for module renaming oca-port#74

[sebalix]

Will change this module_names parameter later, current implementation is a bit crappy but that's OK for now.

[hparfr]

Hi @sebalix

On a module branch form, managers are able to qualify the current module with 3 options regarding the next Odoo version:

I think we have two layers of information here:

• 1. from github scans : stock_packaging_calculator has been renamed product_packaging_calculator
• 2. from the project manager: keep oca/storage/storage* or move on oca/storage/fs_*

2. is "by project" while 1) is system wide.

In your capture, I don't get what is next version for a v16 project targeting v18.

[sebalix]

@hparfr indeed, and for now I only focus on the first (system wide / global info that should benefit to all projects). If we flag a module as replaced, we focus on the nearest one technically speaking (could be replaced by a collection of modules, but still we target only one for the sake of simplicity to get at least the info that current module is not maintained anymore and has been replaced by something else).

And later I would like to improve the project modules entries within a migration, to put the "by project" info as you say:

• if we don't keep this module (i.e. customer project doesn't need it anymore)
• if we replace a module by another one (storage_x by fs_x)
• set a label/tag on project modules, for instance to group them by "lot" to better plan the migration

You think the "replaced by" choice is not convenient at module level here?

In your capture, I don't get what is next version for a v16 project targeting v18.

I should add the target module name in the list view to see the new module at a glance.

[sebalix]

@hparfr About the discussion we had regarding the place where to store renamed modules. Should we not consolidate the efforts in OpenUpgrade instead in the apriori file?

• https://github.com/OCA/OpenUpgrade/blob/18.0/openupgrade_scripts/apriori.py

It's not the same format but I believe having only one place where to put this information is better to ease community work.

[hparfr]

I think it's good to decouple things.

Having a single bdd on git with only one branch allow us to have more fine grain control on permissions for merge and exclude all kind of conflicts.

Then with a CI from this repo we can generate part of the apriori.py file.

[sebalix]

After some tests, seems to work as expected, merging as-is to avoid too much conflicts with the next PR.