Fix version detection for branch layout with /

[m-chalin]

With commit 3ec0f7e runbot supports branches with /.
But the version detection was not working for branches like 19.0/foo.

[Xavier-Do]

Hello and sorry for the delay

I tried to define the purpose of your change and to be honest, it looks like even if it could work in some cases, I don't really get how it could work in a standard git repository since you cannot have both a 18.0 and a 18.0/dev branch

We could imagine to support dev/18.0-something

What do you think ?

[m-chalin]

Hello @Xavier-Do,

Thanks for your feedback!

You are completely right that in a standard, single Git repository you cannot have both a 17.0 branch and a 17.0/ folder structure due to how Git stores references.

However, in our setup, we use runbot with a mixture of different branching models across multiple repositories. For example:

• For odoo and odoo-enterprise, we stick to the standard 17.0 branch.
• For our own custom addons (stored in separate repositories), we follow a structure like 17.0/dev, 17.0/staging, and 17.0/production.

While we can manually set the base version for these main custom branches once, our developers also follow a branching model like 17.0/USER_feature_branch for their daily work. This PR would help runbot automatically and correctly detect the version prefix for those nested developer branches without breaking the existing hyphen-based detection.

Does this context make sense? Let me know what you think!

Best regards,
m-chalin

[Xavier-Do]

But the problem is that you need a 19.0 branch as a base branch to automatically match the 19.0 odoo/enterprise one.
Without that a bunch a feature won't work like like auto-filling the base commit if you have multiple repos, defining the base commit, ...

[m-chalin]

Hello @Xavier-Do,
Thank you for the follow-up — I understand your concern, and I agree that runbot needs a proper 19.0 base bundle (typically from the odoo/enterprise main remote) for multi-repo features like base commit auto-fill to work correctly.
That is exactly how we run it:

• We have 19.0 as a base branch/bundle on our main remote (odoo/enterprise).
• Our custom addon repos only use slash branches (19.0/dev, 19.0/staging, 19.0/USER_feature) — no flat 19.0 branch there, which is fine because those repos are not base repos.
• For the main custom branches (19.0/dev, etc.) we set defined_base_id once to point to the 19.0 base bundle.
• This PR only extends the existing prefix matching so that developer branches like 19.0/USER_feature are automatically linked to the same 19.0 base bundle — the same way 19.0-dev-tri already works with the hyphen prefix.

We have been running this patch in production for a while now and version detection, bundle grouping, and multi-repo builds work as expected with this setup.

I understand this is a niche use case and that upstream may prefer the dev/19.0-something naming convention to avoid the Git ref conflict in a single repo. If you feel this pattern is not something runbot should support generically, I'm completely fine with closing the PR — we'll keep the patch in our fork. I just wanted to share that it does work in practice when the base bundle is properly defined on the main remote.

Thanks again for reviewing!
Best regards,
m-chalin

[Xavier-Do]

To be honest the structure 18.0/dev-branch looks interesting and I have no objection to make change that can improve the experience for other runbot users. My issue here is that it may work for your use cases but some features may be broken when using such branch format that could be hidden in the code base, and that you didn't notice because you don't care or you don't use the specific feature.

I don't have an exhaustive list of what could break in mind, but having only the 19.0 in odoo and enterprise and not in your custom repo is not expected. Without a 19.0 branch in your project, I can't really figure out how the mergebase can be defined for diff bases checkers, and how the best commits can be found based on the mergebase too (maybe not a big issue for you)

Maybe that you have another branch from your repo in the 19.0 base bundle that will be used.

In any case we if we add such an hard coded way to define a branch, it would look like it is supported and it is not really the case.

Wa already have some way to tweak the runbot behaviour using icp, as an example for the runbot_is_base_regex that should allow to define custom version format in theory.

To cover your use case we may define a _get_version_prefix that could either use an icp defined regex, or could be overridden on your side easily

I prefer the _get than _has version to make it more versatile.