You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to have a generic module that handles connections to GitHub/GitLab.
This way, we avoid re-implementing repository logic, GitHub organization management, and PR handling in odoo-repository, partner-module, and whatever the OCA will need for its stats.
Note: I am going to propose a PR for extracting the generic data model for odoo related stuff (odoo.version, odoo.serie, odoo.module....). This based module will be here and will be used as dependency for odoo-repository modules and for partner-module-information https://github.com/akretion/partner-module-information (I will move partner-module-information here)
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
I was a little surprised to discover the existence of the OCA/version-control-platform repository, which seems to be created after this repository and seems to provide much of the same core functionality.
Is there an issue, discussion, or any other documentation explaining the motivations behind this decision and the choice to start a new implementation rather than further developing this one? I'd be interested in understanding the context and the trade-offs that led to this approach.
I'm sure there are areas where this code could be improved, but given the number of use cases already covered here, I'm wondering why this approach wasn't further developed instead of introducing a new implementation in OCA/version-control-platform.
The new implementation is certainly simpler, but it also covers fewer use cases and has less history and fewer constraints to deal with, which naturally makes the code look cleaner. By "simpler", I don't mean this as a criticism of the implementation itself, but I think we should consider the functionality that would be lost by moving to it.
Personally, I'd really like to see these two approaches converge. The use cases currently covered by OCA/module-composition-analysis seem to go beyond what OCA/version-control-platform currently provides, and it would be great if we could build on the work already done here and avoid splitting the effort between two implementations solving largely the same problem. But how can we converge?
Hi @lmignon to be clear, evolution was completly different. it started by taking github data for analytics and it converged with connector-git to become the current solution. it is true that vcp_odoo overlaps a little with this repository, but it is completly different with the other modules.
As I see it, it would be interesting to construct your needs in top of vcp_odoo as it provides a good set that can help. Obviously, I am not an expert on this repository, but I think they could fit together if done properly.
Refactoring all this to be based on top of vcp_ would be a huge effort. Even though, at first glance, the codebase seems cleaner (with less duplication), it is also probable that the base would need to be adapted to support these new use cases (vcp_ was designed with a different use case in mind, even though it was intended to be generic ;-))..
I think @sebalix's expertise is required before we can go much further. As the original author of the module, he has a deep understanding of all the explicit and implicit use cases that led to some of the technical choices that may seem questionable today.
His input would therefore be really valuable in determining whether this is a good path for future evolution. I hope to have the opportunity to discuss this topic in more depth with him over the coming weeks.
Note: I still didn't took time to play with VCP yet, and I don't want neither to be stuck in the future because VCP took a direction that is not compatible with MCA. I need to check VCP in details before going ahead.
Now I can still dump the goal of Odoo MCA here and what I have in mind in the future.
Back in 2023, my goal was to get an exhaustive collection of Odoo modules within the ecosystem, and quickly get informations to "estimate" a migration project. Entities like "Odoo repository", "Branch", "Repo Branch", etc have been implemented, but we can find the same in VCP modules, and our wish with @sebastienbeau was to re-use them in Odoo MCA if possible (yes that will be a huge effort).
How it has been thought initially:
an Odoo instance used internally by any Odoo integrator (dev & functionals), to centralize data regarding the Odoo ecosystem, and map these data with internal projects to get some internal stats about Odoo CE, Odoo EE or OCA modules usage;
optionally having a central node (hosted in OCA) that will clone/parse main repositories, and Odoo integrator nodes could fetch these data into their local node containing only private projects data (but it stayed as an idea);
declare the migration paths we are interested in (e.g. 16.0 -> 20.0) to get migration data computed for that path ("is this module ported or partially ported?"), using oca-port internally;
declare "timelines" => how modules evolved from one version to another (like "apriori" files in OpenUpgrade). I would like to extend this to data models, fields and methods, and why not code patterns;
able to scan custom branches (like main) for a given repository, but qualify it as 18.0. But it is not designed at all to scan development branches or forks, only main/upstream branches/repos;
I wanted the scanner part in a dedicated library initially, but without queue_job to orchestrate job dependencies it's kind of useless alone, or it would require some work anyway. For now I keep it here;
improve timelines to support data models/fields/methods evolutions
use this whole database as a RAG through a MCP used by your preferred AI agent to answer technical or functional questions, and mainly to help migrating modules (switching dependencies, data model/field merge/renaming etc);
as migration data computation takes a lot of time (we should limit them only to migration paths we are interested in, and archive old ones to reduce computation), I would like to replace oca-port usage here and test importing all git history in PostgreSQL, and do the computation there to compare commits, it'll reduce I/O a lot (linked to Import modules git commits data #132 );
with git commits imported, AI could automatically generate timelines in a draft state, validated by developers;
cleanup: remove the "addons path" data model, such info could be automatically detected when scanning a repository
We could discuss all of this during OCA Days 👍
Reacted by Laurent Mignon (ACSONE) and Enric Tobella
Thank you @sebalix for your feedback. I'd be happy to discuss this topic with you during the OCA Days. The work you've done on this repo, for example to provide a clear picture of the effort required to migrate a project, is really impressive and, I think, deserves much more recognition. 😏 I hope I'll have the opportunity to actively contribute to this project in the future.
Activity
hparfr commentedon Jan 27, 2026
I didn't find the objectives of vcp.
Before changing the foundations of mca, it can be good estimate the tradeoffs / benefits
sebastienbeau commentedon Jan 27, 2026
The idea is to have a generic module that handles connections to GitHub/GitLab.
This way, we avoid re-implementing repository logic, GitHub organization management, and PR handling in odoo-repository, partner-module, and whatever the OCA will need for its stats.
Note: I am going to propose a PR for extracting the generic data model for odoo related stuff (odoo.version, odoo.serie, odoo.module....). This based module will be here and will be used as dependency for odoo-repository modules and for partner-module-information
https://github.com/akretion/partner-module-information (I will move partner-module-information here)
github-actions commentedon Jul 26, 2026
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
lmignon commentedon Aug 18, 2026
@etobella @sebastienbeau @legalsylvain @sebalix What's the current status of this issue?
I was a little surprised to discover the existence of the
OCA/version-control-platformrepository, which seems to be created after this repository and seems to provide much of the same core functionality.Is there an issue, discussion, or any other documentation explaining the motivations behind this decision and the choice to start a new implementation rather than further developing this one? I'd be interested in understanding the context and the trade-offs that led to this approach.
I'm sure there are areas where this code could be improved, but given the number of use cases already covered here, I'm wondering why this approach wasn't further developed instead of introducing a new implementation in
OCA/version-control-platform.The new implementation is certainly simpler, but it also covers fewer use cases and has less history and fewer constraints to deal with, which naturally makes the code look cleaner. By "simpler", I don't mean this as a criticism of the implementation itself, but I think we should consider the functionality that would be lost by moving to it.
Personally, I'd really like to see these two approaches converge. The use cases currently covered by
OCA/module-composition-analysisseem to go beyond whatOCA/version-control-platformcurrently provides, and it would be great if we could build on the work already done here and avoid splitting the effort between two implementations solving largely the same problem. But how can we converge?Kind regards,
Laurent
etobella commentedon Aug 18, 2026
Hi @lmignon to be clear, evolution was completly different. it started by taking github data for analytics and it converged with connector-git to become the current solution. it is true that vcp_odoo overlaps a little with this repository, but it is completly different with the other modules.
As I see it, it would be interesting to construct your needs in top of vcp_odoo as it provides a good set that can help. Obviously, I am not an expert on this repository, but I think they could fit together if done properly.
lmignon commentedon Aug 19, 2026
Thank you for your feedback, @etobella.
Refactoring all this to be based on top of vcp_ would be a huge effort. Even though, at first glance, the codebase seems cleaner (with less duplication), it is also probable that the base would need to be adapted to support these new use cases (vcp_ was designed with a different use case in mind, even though it was intended to be generic ;-))..
I think @sebalix's expertise is required before we can go much further. As the original author of the module, he has a deep understanding of all the explicit and implicit use cases that led to some of the technical choices that may seem questionable today.
His input would therefore be really valuable in determining whether this is a good path for future evolution. I hope to have the opportunity to discuss this topic in more depth with him over the coming weeks.
sebalix commentedon Aug 19, 2026
Thank you for your feedback on this.
Note: I still didn't took time to play with VCP yet, and I don't want neither to be stuck in the future because VCP took a direction that is not compatible with MCA. I need to check VCP in details before going ahead.
Now I can still dump the goal of Odoo MCA here and what I have in mind in the future.
Back in 2023, my goal was to get an exhaustive collection of Odoo modules within the ecosystem, and quickly get informations to "estimate" a migration project. Entities like "Odoo repository", "Branch", "Repo Branch", etc have been implemented, but we can find the same in VCP modules, and our wish with @sebastienbeau was to re-use them in Odoo MCA if possible (yes that will be a huge effort).
How it has been thought initially:
oca-portinternally;main) for a given repository, but qualify it as18.0. But it is not designed at all to scan development branches or forks, only main/upstream branches/repos;queue_jobto orchestrate job dependencies it's kind of useless alone, or it would require some work anyway. For now I keep it here;My roadmap :
oca-portusage here and test importing all git history in PostgreSQL, and do the computation there to compare commits, it'll reduce I/O a lot (linked to Import modules git commits data #132 );We could discuss all of this during OCA Days 👍
lmignon commentedon Aug 19, 2026
Thank you @sebalix for your feedback. I'd be happy to discuss this topic with you during the OCA Days. The work you've done on this repo, for example to provide a clear picture of the effort required to migrate a project, is really impressive and, I think, deserves much more recognition. 😏 I hope I'll have the opportunity to actively contribute to this project in the future.