Contributors mailing list archives

Browse archives


Re: new API vs merges upwards

Camptocamp France SAS, Alexandre Fayolle
- 31/07/2015 12:11:27
On 31/07/2015 11:52, Leonardo Pistone wrote:
> We hit this topic other times, but this time we have a practical example:
> 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