openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

On Thu, Nov 1, 2012 at 2:40 PM, Ray Carnes <rcarnes@xxxxxxxxxxxxxxxxxxx>wrote:

> Can I also suggest adding the recommendations about module versioning from
> OpenERP?
>
> http://doc.openerp.com/trunk/developers/server/module-versioning/
>
> There are many problems that users face not installing the correct
> versions of modules.
>
> Ray.



Hello Ray, the issue is why OpenERP SA version management won't help for
90% of our customers. Concretely it doesn't work for e-commerce connnectors
or complex localizations such as here in Brazil.
And if you also read what it takes to manage a "normal" non e-commerce non
crazy localization deployment, you also understand why it won't work
http://people.via.ecp.fr/~alexis/openerp/
(150 modules to manages; with no version management??)

I detailed the explanation here:
https://lists.launchpad.net/openerp-expert-framework/msg00925.html
and here:
https://lists.launchpad.net/openerp-expert-framework/msg00926.html
why this doesn't work for complex added value modules.

Also one precision: why did I suggest enabling to explicit a dependency
branch? Well until you you have version management working, this is easier
to get working: version management can only work if you can track all
existing OpenERP module and versions. What will do that? apps.openerp.com?
Today it only works for bzr, when branch are duly registered and we have no
control over how broken it is. So instead of depending on that, I prefer
having the job done. Of course, once some module repository would properly
index all modules no matter how they are hosted, then may be version
management could be more than just a hint for developers.
Also some can have memory short, but may be some remember about: RML
engine, integrated BI, integrated ETL, MySQL branch, Dia RAD tools and many
other such ""things"". So sorry but if I put not faith in non community
hardened things like apps by default it's because I have reasons for doing
so.

Also, if somebody disagree whit my explanations, then feel free to comment
in that previous thread.


Now how does it relate to continuous integration testing?
Well if modules don't enforce the proper dependencies versions in their
meta-description format, then there is no hope that automated runbots will
be able to automatically retrieve the proper dependencies.
This is the very reason I put then no faith in OpenERP buildbot to test
complex added value modules. If they end up listening fine, but if they
don't we need to get the job done anyway.
Then we are left with manually enforcing the proper dependencies branches
in installation recipes at such as Anybox recipes (at Akretion or
CampToCamp from what I know our experienced made us use even more complex
deployment strategies).
But IMHO in any case it sucks to have to manually write a particular recipe
for any module combo you want. Dependencies management usually fixes that
for us, and no this is not rocket science.

Notice that recipes for automated testing are still pretty human to write
for use developers (not for the end users, that's the point).
For instance, this is close to all what is needed to test all OpenERP
official addons with the standard test suite at every commit on the Github
mirror:
https://github.com/rvalyi/openerp-addons/blob/master/.travis.yml

I can imagine that with 5 lines more we could also test things like
Magentoerpconnect the same way. The good point is that anybody would be
able to have CI testing on their branch easily without having to ask
anybody's permission or suffer third party bugs (akretion-team is now out
of the OpenERP runbot just because /a in the URL was a command, that is
because of a runbot bug)...


Finally, I let you know that I'm improving Sebastien's scripts to extract
the extra-addons. It seems I'll have it all automated today. I'll post
updates soon.


Regards,



-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com