Contributors mailing list archives


Re: Confusion about branch 9.0 in github

Landis Arnold
- 13/11/2015 14:56:31

I concur with Rafael's recommendation of making 8.0 the default branch. Many people start by browsing Github and where they start makes a strong impression.

I would also say that V9 itself should be renamed to V9-DEV (or similar) and not change  till either a BETA or RC version. 

Of course the constant state of change complicates this, but it would help "end users" and minimize support type explanations of what is working and what is not.

Also, use Github Wiki for ongoing documentation about status of the whole project and its process.

My thoughts anyway.

Landis Arnold
Cell. 303.601.0622
Office. 303.444.2336

Please excuse my mobile phone typos

From: Raphaël Valyi <>
Sent: Nov 13, 2015 5:53 AM
To: Contributors
Subject: Re: Confusion about branch 9.0 in github

An other thing that could be done might be switch 8.0 again as the main branch for say one more month.
I kind of feel the state of v9 regarding to accounting (what average user expect from an "ERP") is such that delaying like 1 more month before talking about v9 would save many users from doing a terrible mistake that may turn them away from the Odoo community.
Well only a suggestion...

On Fri, Nov 13, 2015 at 10:23 AM, Guewen Baconnier <> wrote:
You consider that a migration is a 2 commits work which is silly if the addon is a bit elaborated.
A unique commit for a migration seems utterly wrong to me in many situations.

I will never ever migrate 'connector' or 'magentoerpconnect' in one commit. Even smaller addons I wouldn't, when you work on a migration, you often have to make choices, for instance when you fix a bug or when you have to change a feature, this is in the commits that it should be documented and you shouldn't mix them all.

We **must not** break good commits practice just because some users are confused because they don't read a readme file.

On Fri, Nov 13, 2015 at 11:53 AM, Daniel Reis <> wrote:
Guewen, there is a solution for the review diff:
Ask the author to do the migration work in a single commit, and then 
review only that commit instead of the full diff.
Personally, there are times where I want to review untouched parts of 
the code, so if a also have the full module diff I would find that useful.

In a nutshell:
- For authors, the work to port from 8.0 to 9.0 is about the same in 
each solution (see Pedro's link).
- For reviewers, focusing in the migration changeset commit solves the 
review effort issue.
- For "end users" it is clear about what modules are available.


Post to:

Post to:

Raphaël Valyi
Founder and consultant
+55 21 3942-2434

Post to: