1. Mailing Lists
  2. Italy
  3. Re: Problema moduli oca e versioni manifest

Italy mailing list archives

italy@odoo-community.org

Browse archives

Transbot

Avatar

Re: Problema moduli oca e versioni manifest

by
TAKOBI s.r.l., Lorenzo Battistini.
- 23/01/2019 12:32:16
Per aggiornare automaticamente il requirements.txt ci sono degli strumenti automatici. Io ad esempio uso questo https://github.com/simion/pip-upgrader con questa fix https://github.com/simion/pip-upgrader/pull/16
Fondamentalmente, credo sia esattamente la stessa cosa, in fondo... No?
Non specificando le versioni all'interno dei "requirements.txt", sto delegando a PIP il compito di capire quale sia l'ultima versione e di installarla...
Specificando, invece, le versioni e usando il tool da te indicato, sto delegando a quest'ultimo il compito di capire quale sia l'ultima versione lasciando il compito a PIP di installarla...

Per chiarezza: il tool lo uso per modificare il requirements.txt, che controllo poi visivamente. Non installo mai automaticamente moduli aggiornati, senza controllare quali moduli aggiorno e a che versione.

 
pip ed il requirements.txt non sono nati per disinteressarti delle versioni che installi. Ovviamente se vuoi puoi farlo, a tuo rischio e pericolo.
Il fatto di andare a prendere, in maniera automatica, sempre l'ultima versione "stabile" ovviamente, non è sinonimo di disinteressarsi alle versioni che si sta andando ad installare...

Non è detto che l'ultima versione stabile sia quella che vada bene per la tua installazione. E questo vale per i moduli odoo come per qualunque pacchetto python, come ad esempio le dipendenze di odoo.

 
Senza contare che, se l'incremento della versione fosse davvero un requisito obbligatorio, sarebbe un ulteriore livello di controllo aggiuntivo sui moduli rilasciati.

Certo, infatti la versione dovrebbe essere sempre incrementata nelle PR, seguendo le linee guida per il versionamento.

 
Mi immagino già situazioni di questo tipo, su GitHub...

"In questa PR, non hai fatto modifiche sostanziali, alle funzioni del modulo... Si tratta, più che altro, di modifiche alla vista. Non incrementare la versione del modulo."
... oppure...
"In questa PR della FatturaPA, c'è ancora quel discorso famoso di quel caso particolare... Non è, del tutto, stabile. Manteniamola come versione DEV. Non incrementare la versione."

No, non funziona così. La versione andrebbe sempre incrementata, vedi sopra. Ma se non viene incrementata, non è per scelta, è per dimenticanza.
Il livello di stabilità, o maturity level, è gestito dalla chiave development_status. Vedi OCA Maturity Levels and Development Status Policy.

Il messaggio che volevo passarti però è: non farti problemi a installare un modulo OCA DEV, perchè non è DEV, è stabile.


 
Quella che chiami ultima versione stabile, per OCA è una versione vecchia. [...]
A te, questa cosa, davvero non "puzza" (almeno un pochino)?
Non ti sembra che ci sia qualcosa di sbagliato, in un qualche punto, del flusso?

Sì 😀
Ma ti stavo spiegando come funziona ora, per rassicurarti sul fatto di utilizzare versioni "DEV".

 
Com'è possibile che vengano rilasciate due versioni dello stesso software, su due piattaforme diverse, che devono essere interpretate in maniera differente?
Quello che, da una parte, è definito "stabile", dall'altra è "vecchia" e, al contrario, quello che è definito "stabile" dall'altra è definita "instabile"?

Solo io ci vedo qualcosa di terribilmente sbagliato?

---


Non oso neanche immaginare se, un caso del genere, fosse legato a del software rilasciato direttamente da Microsoft... Apriti cielo! 😂


Ovviamente si possono studiare e proporre soluzioni migliori.
Ad esempio essere più rigidi sul versionamento nelle PR e automatizzare l'incremento di versione per i commit di traduzione.

Penso che il posto migliore per discuterne sia la mailing list contributors.

Reference