1. Mailing Lists
  2. Contributors
  3. Re: new API vs merges upwards

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: new API vs merges upwards

Re: new API vs merges upwards

Avatar

Re: new API vs merges upwards

by
Open Architects Consulting, Houssine BAKKALI
- 31/07/2015 13:48:23
my thinking about porting to v8 and to the new api for modules coming from v7 and previous one is that we mix to different needs. the first one is having the functionnalities ported to v8, the second ones is having the module using the new api.

but sometimes these two needs enter in conflict and in slow down the porting process in all the cases(bigger dev effort and make the code review more complicated) and you loose the stability of a used module in the previous version.

my though is that we should not ask for porting to the new api for module existing in the previous version. But well with the new ones except in some case that has to be defined.

I'm talking for my case where i'm not yet fluent in the new api.

2015-07-31 12:22 GMT+02:00 Alexandre Fayolle <alexandre.fayolle@camptocamp.com>:
On 31/07/2015 11:52, Leonardo Pistone wrote:
> We hit this topic other times, but this time we have a practical example:
> 
> https://github.com/OCA/stock-logistics-workflow/pull/132/files#diff-cfbfcae8295adcadf086ea7bfa09b21dL185
> 
> What happened is that the v7 of a module was improved, and in the
> merge upwards of 7 to 8, I resolved the conflict choosing the v7
> version. In that specific case I thought that I was just throwing away
> two trivial new API lines for a big win.
> 
> I do not think there is a good solution to that. Even the solution of
> porting the method to v8 is not ideal: the fresh v7 code is in
> production somewhere, and if it breaks we'll sure post a fix, bringing
> us back at square one. The new API port will be unused by us for the
> moment, hiding new bugs for a while.
> 
> Odoo SA does upwards merges regularly, but only because they did very
> little porting to the new API. In our case, I'm not sure if it's worth
> it.
> 
> What do you think on the subject?

Following the Zen of Python

"""
[...]
Although practicality beats purity.
[...]
"""

I'd rather have the fixed version in 8.0 now than an untested port to
the new API, especially since the new code apparently does not come with
an automated test.

Forward porting fixes from 7.0 to 8.0 new api is going to be a real
problem in the future.

We don't have a policy mandating the new API in OCA 8.0 branches, so we
are somehow in the middle of the stream here. I think we will have to
reevaluate this policy when we start porting our addons to 9.0. Maybe we
shall enforce the use of the new API on that branch (when it does not
break the addon, such as some onchange, AFAICT), and then try to take
the opportunity of bug fixing in 8.0 versions of the addons to complete
the migration to the new API in 8.0 so that the fixes can be easily
forward ported to the 9.0 branch.




-- 
Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

_______________________________________________
Mailing-List: http://odoo-community.org/groups/oca-contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


Reference