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

Avatar

Re: new API vs merges upwards

by
MoaHub, Graeme Gellatly
- 31/07/2015 22:59:38
I think it is entirely situation dependent

If there are API related conflicts then probably no.
If it is a new module or added functionality to an existing module then probably no (i.e. new stuff should be new API, even if mixed with old)
If it is existing module or existing functionality and it is in old api then probably yes.
If it has scratchy test coverage then tests first, new API later.
If it fails test, well definitely no.

It is essentially a cost/benefit analysis - is the benefit I get today from having this code available worth the pain of tomorrow, vs the cost of porting while it is fresh in your mind.  Or the cost of waiting.  For people who don't know the new API, you need to learn sometime, best to learn with something you know and understand.

But also I think individual repo maintainers should be able to create a rule that suits them.


On Sat, Aug 1, 2015 at 12:22 AM, <Pedro@pad.odoo-community.org> wrote:
Stability is not problem with a good test coverage (that it's the goal we should achieve), and we are talking here about merging changes in a previous version branch in the later one or make the patches in both branches (or not, because the newer branch maybe is not affected because it's an API (or related) problem, like a context propagation).

That's why I prefer (when possible), to have new API as soon as possible, and let tests to check possible regressions.

Regards.

2015-07-31 13:52 GMT+02:00 Houssine BAKKALI <houssine.bakkali@gmail.com>:
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


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


_______________________________________________
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