Proposal: Modify OCA's module version policy to use only 2 numbers

[yajo]

Currently, OCA's guidelines mandate that module versions use 5 numbers like in a.b.x.y.z. The a.b indicate the Odoo version. The x.y.z indicate the module version.

After some diving on Odoo's migration system, it turns out that there are 2 kind of migration scripts:

• Those that have 2 . or more assume that the Odoo version is included. Example: migrations/15.0.0/pre-migrate.py will only run on Odoo 15.0, when the module version is bigger than 0.

• Those that have 0-1 . assume that the Odoo version is not included. Example: migrations/15.0/pre-migrate.py will run on any Odoo version, if the module version is bigger than 15.0.

There's also special support for folders named 0.0.0, but that's out of scope.

Since OCA's version indicators (without Odoo version) have 3 number positions, they have always 2 dots. Thus, it's impossible to make a migration script that serves for multiple Odoo versions.

Most odoo modules only use 2 numbers in their versions. I think OCA should follow that.

However, changing this would impact many tools, such as the docs, ocabot or pylint-odoo.

OTOH, maybe it's not so problematic, as long as this is a known behavior. Patch releases usually don't need to trigger migrations. But I think it's worth pointing out somewhere that that migration script folders should be named:

• a.b.x[.y[.z]] if you want version-specific migration scripts, or
• x.y if you want to use the same migration script across multiple Odoo versions.

[legalsylvain]

Hi @yajo. Thanks for sharing. I'm not sure to understand all the advantage for such a change. You talk about the "impossibility to make a migration script that serves for multiple Odoo versions". Do you see any other advantage ?

[yajo]

No, it's the only one I see.

[simahawk]

Hola :)
If I get it right, you are saying that for their special migration machinery to support x.y migration script they want the module version to have only 3 digits?

If that's the case, I wonder if we cannot propose a fix for it. I mean, why can't you support mig folder names to be w/ only 2 digits if the module's version is not 3 digits? Or... I don't get the rationale behind it :)

[yajo]

I don't think that can be fixed at this point in history. A lot of migration scripts must be written in Odoo's private upgrade repo, which support this specific behavior. IMHO it's more practical to assume and accept it.

Maybe their rationale was that no patch release for a module needs a migration script. If it needs it, it must be at least a minor increment.

In any case, the point is that a folder 1.0.0 gets interpreted as "Odoo v1.0, module v0", not "module v1.0.0" as it might seem.

[legalsylvain]

I'm not sure to understand what you propose :

• having a single branch with modules that work with many odo versions ?
• having a branch per odoo version, but just changing the version key in the manifest. (15.0.1.0.0 -> 1.0) ?

[yajo]

• having a single branch with modules that work with many odo versions ?

That'd be great, but the world isn't ready (yet).

• having a branch per odoo version, but just changing the version key in the manifest. (15.0.1.0.0 -> 1.0) ?

This goes more in line of my thoughts.

If you add a feature to a module, that requires a migration, in 15.0.2.1.0 but then you fwport it to 16.0.1.2.0, then you can't reuse the same migration script. Thus, when you fwport that change, you need to alter the name of the migration script folder.

If we, instead, get the a, b and z steps out of the picture, we could share the same x.y version accross all branches of the same module, giving potential to reusability of migration scripts.

[theangryangel]

x.y if you want to use the same migration script across multiple Odoo versions

I’ll be upfront, I’m running on very little sleep and very long days the last week, so this might be me missing something obvious. If so, forgive me..

But whats the scenario where this something that is likely to popup? Or is this “just incase so it doesn’t cause footguns later”?

[yajo]

See https://github.com/orgs/OCA/discussions/117#discussioncomment-7206938.

Honestly it's probable that this won't happen because the version in OCA modules is mostly meaningless in the sense that you can't know in which version of the module a feature or fix landed, just because the versions aren't in sync across odoo releases.

It'd be much simpler if all OCA modules just had x.y versions in their manifests.