Vo, I released I rejected your idea without explaining enough (well I told you that while I we mate in Belgium, so I assumed you wouldn't have forgot it) but it doesn't cost much, I'll explain again: so here are more details why I cannot accept your development iteration proposal:
In the real life (ecommerce connectors, localiztions...), we keep moving modules forward using the same approach as feature branches (the same thing you do to develop new versions of OpenERP): we test a short iteration to improve something, deploy it at a customer and then if it's OK, invest in consolidating it in the main branch and upgrading our other customers to keep in sync. But because we aren't paid by partnership renewal to develop things in the dark during one year, we actually deploy what we develop at our customers in short iterations; less than 3 months typically. So unlike you their isn't some blessed claimed "stable" release all the sudden. And because we are actually in contact with the ERP users, we should actually fix it even if we dared to call it stable previously (imagine you should actually deploy all those OPW fixes you never merge back into the stable releases). Then, during those cycles, If I follow your "M N X modules" methodology you just gave, I'll have two terrible problems: 1) I'll keep changing my module names which will make code comparison challenging for not benefit and will immediately deprecate documentation 2) but more importantly: all ir_model_data references from the dependent module WILL HAVE TO CHANGE to keep pointing to those modules records!!! So it means as soon as we try to improve some abstract module, we should immediately fork all dependent modules -> this is totally wrong! I'm not talking about abstract problems here. Let's give a concrete example: see how we are here evolving/cleaning all Magentoerpconnect modules in some intermediary branch: reasonably stable 6.1 version: https://code.launchpad.net/~magentoerpconnect-core-editors/magentoerpconnect/module-magento-trunk new 6.1 cleanned version that is now cleaner and will soon be promoted to the main 6.1 branch to use: https://code.launchpad.net/~sebastien.beau/magentoerpconnect/oerp6.1-cleanning So what just because in oerp6.1-cleanning we are also evolving the intermediary abstraction dependence modules, we should also hack all our terminal magentoerpconnect XML to accomodate to the module names changes and also hack all our customer database with SQL to accomodate those evolutions? One of our customer in the USA where OpenERP SA is selling a Magentoerpconnect project (with us) ran into that very issue exactly today, how can you claim there is no problem? Seriously, this is not going to work! Please consider my proposal again. SCM Branches are all about managing the those feature branches. Other major open source component all embrace dependency management. Come on, how can a guy like your CTO Antony claim that OpenERP would more challenging than Linux (he repeated me that several times) while you could still afford not doing what all Linux distro have done long ago by adopting package management with dependencies tracking? Why try to reinvent non working convention instead of biting the bullet for once? -- https://code.launchpad.net/~openerp-dev/openobject-server/trunk-module-versioning-vmt/+merge/128668 Your team OpenERP R&D Team is subscribed to branch lp:~openerp-dev/openobject-server/trunk-module-versioning-vmt. _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-gtk Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-gtk More help : https://help.launchpad.net/ListHelp
