On Mon, Apr 28, 2014 at 11:25 PM, Antony Lesuisse <[email protected]> wrote:
> Sorry for being rude, my point here was simply that if somebody really > wants something it's probably easier to work on it than to convince someone > else to do it. > > For OpenERP Enterprise customers, our the migration service will find a > solution for a smooth upgrade path on specific basis. (most likely > base_action_rules). Maybe they will fix the module to make it work for v8. > But this will happen after june. > > We decided to move auditail to extra (with other modules) as we think they > dont meet the quality standard for a long term release and we have > alternative solutions to the use case (althought not fully equivalent). > Auditrail in trunk is broken since 1 year and the only MP about it was made > by Stefan Rijnhart 2 years ago. > > I want to close the merge window for v8 and we will merge wms this week > and new api next week (not sure 100% yet). So even if we fix auditrail it > will be later and the module wont be part of v8. > Hello Antony, I respect the concern of impacted people, but I also agree that is was shitty code and I'm not angry when OpenERP SA is focusing on the core modules. But as you are talking about feature freeze, I'm squatting the thread to react to this important topic that never has a chance to surface: during a release life cycle we are often opposed that merge proposal X cannot be done because it would break the API or the database schema. But sometimes this is really a major hassle for modules depending on OpenERP, such as the localizations because modules are badly incompatible between them where the average OpenERP customer would expect things work out of the box when adding modules. I also understand you don't have enough resources to review the hundreds of community merge proposals submitted every year. But is there a way the OCA or whatever other form of community organization could promote a limited set of merge proposals focused on the API and only on the API changes? In a good release policy, you use something like semantic versioning and you really take advantage of new major release to concentrate the necessary API evolution. Most of the bugfix on the contrary can happen later without requiring API changes. Many new feature can also happen in extra modules without monopolizing the focus of the new release. But API change should take place during these rare moments. This has really a lot's of consequence on the size of the overall OpenERP user base later. Bad API -> bad localization / incompatibles verticals -> no user, no business etc... A concrete example of what I'm talking about is: https://code.launchpad.net/~camptocamp/openobject-addons/trunk-refactor-po-merge-lep/+merge/216841 (code to make merging purchase order modular so extension modules can inject their proper behavior) Is there a way and a deadline, OCA can do the sorting work to promote you the most required while simplest API evolutions? Regards and kudos for the work on v8 -- Raphaël Valyi Founder and consultant http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> +55 21 3942-2434 www.akretion.com
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
