Contributors mailing list archives


Re: black version upgrade for v14 ?

Ygol InternetWork, Yves Goldberg
- 04/10/2020 13:24:40
+1 for option #3

----- Original message -----
From: "Pedro M. Baeza (Tecnativa)" <>
Subject: Re: black version upgrade for v14 ?
Date: Sunday, October 04, 2020 16:06

I also go for option 3, and the steps to migrate to v14 will keep the pre-commit step for any possible difference between 13 and 14.


El dom., 4 oct. 2020 14:52, Yannick Vaucher <> escribió:
As I understand you are asking about the default. 3. Seems the best option.

Let's go with newer version an 14.0.

13.0 branches are in different shapes depending on the activity of each PSC.

And as it's hard to predict the effect of the black upgrade on branch 13.0 we shouldn't enforce it on the main branch. However, we could automate the creation of an OCA branch 13.0-black-20.8b1 to make a PR that requires the PSC approval in version 13.0 on each repo.

Would that qualify to a 3b option ?


Le dim. 4 oct. 2020 à 14:22, Stéphane Bidoul <> a écrit :
Hi contributors,

I have a question for you, before creating the 14.0 branches. (I hope
it will not degenerate into a religious war, but I want to ask
nevertheless :)

The black code formatter we use has a new version that, among other
fixes and improvements, resolves the infamous trailing comma issue
[1]. It also does some reformatting in the docstrings. When we use it,
it therefore applies some different code reformatting here and there.

In the long run, using it is definitely a good thing. In the short
term I'm not so sure, hence this message.

So I see 3 possibilities:

1. keep black to the same version in 13 and 14 and wait until black
hits 1.0 to upgrade

This is the less disruptive approach right now but we need to continue
coping with the trailing comma "bug". This postpones the moment when
we will need to decide between options 2 and 3 below (possibly
involving more branches).

2. upgrade black now in 13 and 14

We can automate that but it will have the drawback of making some
existing 13.0 green PRs unmergeable, requiring manual intervention on
them before merging.

3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in
13 if they want to.

With this approach there will be some code formatting differences
between branches 13 and 14 which may make code migration slightly more
difficult, and may create some cherry-pick conflicts in forward- and

What are your thoughts / vote? In doubt, update
.pre-commit-config.yaml in your favorite repo to replace 19.10b0 with
20.8b1 and run "pre-commit run -a" to see what it does exactly.

[Note A similar reasoning exists for prettier but it mostly impacts
javascript-heavy repos only. So there I believe it's ok to upgrade
prettier in 14 and keep it as is in 13, especially since there were
some hacks necessary to use it in 13 that we don't want to carry over
in 14]





Post to: