1. Mailing Lists
  2. Contributors
  3. Re: 14.0 branches

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: 14.0 branches

Re: 14.0 branches

Avatar

Re: 14.0 branches

by
Vauxoo, Moisés López Calderón
- 09/10/2020 20:09:25
> Doing both if it's the contributor's responsibility to maintain oca_dependencies.txt and requirements.txt, then I'd say no because it will create additional burden on contributors.

Ok, how did you plan restore old behaviour like your first thread told us?
 - "Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml"

Without these files the old behaviour is disabled totally.
Is not?

> 2a. do people rely on the presence of oca_dependencies.txt and requirements.txt in their workflow ?
2b. do we want to guarantee their presence and correctness ?

For us today the answer for both are: yes

We are deploying using these files today.
In fact, we have a report of each sha and you can open a url with production sha vs staging one in order to see what changes were created.
In this report we have a warning if there is a repository with custom changes ("git status" feature).
if I like make a custom change for my oca-fork it is not an easy way to redirect all repositories to my organization like oca_dependencies.txt (we only change OCA by Vauxoo in the MQT script)

So, we will be forced to make a Python Package Repository to have our fork green.
I understand that we could loose these features using pip but I like the advantages using pip.

If we were warned a time ago, maybe we could think how to change it or prevent the effects and discuss it.

> That is a double open question, to be debated. 

I agree with you.
This matter should be debated, with a good time before to decide change it

Conclusion
if both builds can't be enabled for 14.0
and 14.0 was already released 1 week ago.
Should we change the current way for 14.0 today even if it wasn't discussed before?

Reference