Odoo sta pubblicando la documentazione utente in un percorso dedicato 20.0, e la sua infrastruttura ufficiale di merge mostra attività di staging attive rivolte al branch 20.0. Questi sviluppi rendono visibili pubblicamente la documentazione e l’attività di sviluppo di Odoo 20. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge) Questi elementi non confermano una data generale di rilascio né indicano che ogni funzionalità, requisito di migrazione e pagina della documentazione sia definitiva. Le organizzazioni dovrebbero distinguere tra preparazione visibile e una milestone confermata di rilascio in produzione. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Odoo ha anche modificato il calendario per la rimozione dei servizi legacy XML-RPC e JSON-RPC. La rimozione è ora rinviata a Odoo 21.1/22, mentre Odoo 20 e 21 mantengono i servizi in forma deprecata insieme a JSON-2. (Odoo pull Docs: 16925) Le integrazioni che utilizzano i servizi più datati non affrontano quindi un evento di rimozione confermato quando eseguono l’upgrade a Odoo 20 o 21. Tuttavia, la deprecazione richiede comunque pianificazione perché la disponibilità in queste versioni non costituisce un impegno a mantenere le interfacce indefinitamente. (Odoo pull Docs: 16925)
Cosa conferma l’attività pubblica di Odoo 20
Almeno una pagina pubblica di documentazione utente è disponibile all’interno della struttura di documentazione 20.0 di Odoo. L’infrastruttura di merge di Odoo identifica inoltre attività di staging per il branch 20.0. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge) Queste fonti possono supportare una scoperta tecnica iniziale, ma non stabiliscono che l’intero set di documentazione sia completo o che ogni modifica in staging entrerà in produzione invariata. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
I team possono usare la documentazione disponibile per iniziare a rivedere i processi aziendali interessati e usare l’attività di staging per individuare aree di sviluppo da monitorare. I budget di migrazione e le date di consegna dovrebbero comunque tenere conto di una verifica successiva sulla documentazione finale, sul percorso di upgrade supportato e sulla build esatta selezionata per il deployment. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Questa distinzione aiuta a evitare di considerare un percorso di documentazione pubblico come prova di un rilascio completato. Le fonti disponibili confermano che il materiale di Odoo 20 e il lavoro sul branch sono visibili, ma non forniscono una checklist completa di accettazione del rilascio. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Il RPC legacy rimane disponibile ma deprecato
I piani basati sull’aspettata rimozione di XML-RPC e JSON-RPC in Odoo 20 dovrebbero essere rivisti. L’impostazione attuale rinvia la rimozione a Odoo 21.1/22 e mantiene entrambi i servizi legacy disponibili in Odoo 20 e 21. JSON-2 è disponibile insieme a essi. (Odoo pull Docs: 16925) Le organizzazioni possono quindi riconsiderare l’urgenza delle riscritture pianificate unicamente per evitare un’interruzione in Odoo 20, continuando però il lavoro necessario per abbandonare le interfacce deprecate. (Odoo pull Docs: 16925)
I responsabili dell'integrazione dovrebbero creare un inventario dell'uso di XML-RPC e JSON-RPC nel codice personalizzato, nei sistemi esterni e nelle connessioni gestite al di fuori dell'implementazione principale di Odoo. Ogni dipendenza può quindi essere assegnata a un responsabile, testata sulla versione Odoo di destinazione e valutata per la migrazione a JSON-2. (Odoo pull Docs: 16925) Poiché il punto di rimozione è indicato come Odoo 21.1/22, la pianificazione dovrebbe seguire la documentazione della versione di destinazione esatta, invece di interpretare quella formulazione come una scadenza di calendario. (Odoo pull Docs: 16925)
Per Odoo 20 e 21, l'uso del RPC legacy è un rischio di deprecazione e di futura rimozione, non una conferma dell'assenza dei servizi. I test di upgrade dovrebbero comunque esaminare autenticazione, gestione delle richieste, comportamento degli errori e i risultati di business prodotti da ciascuna integrazione. (Odoo pull Docs: 16925) La fonte conferma la coesistenza con JSON-2, ma non afferma che ogni chiamata legacy abbia un equivalente JSON-2 identico o che la migrazione non richieda modifiche applicative. (Odoo pull Docs: 16925)
Il rinvio crea tempo aggiuntivo per una migrazione graduale, ma non dovrebbe essere considerato un motivo per lasciare le dipendenze non documentate. Un piano pratico può mantenere le integrazioni esistenti durante un upgrade a Odoo 20 o 21, mentre le trasferisce a JSON-2 prima del punto di rimozione indicato. La tempistica dovrebbe essere rivista se Odoo modifica di nuovo i propri piani di versione. (Odoo pull Docs: 16925)
Aumentano i requisiti minimi di Python e PostgreSQL
Odoo ha scelto Python 3.12 come versione minima di Python per Odoo 20 e PostgreSQL 15 come versione minima di PostgreSQL. (mergebot.odoo.com) Questi requisiti devono rientrare nelle revisioni di idoneità per installazioni gestite autonomamente e altri ambienti in cui l'organizzazione controlla la piattaforma applicativa o database. I sistemi al di sotto di uno dei due minimi richiederanno modifiche della piattaforma prima di poter essere considerati rispetto alla base Odoo 20 indicata. (mergebot.odoo.com)
I controlli di versione dovrebbero coprire gli ambienti di sviluppo, test, staging, produzione, ripristino dei backup e disaster recovery. Le immagini di build, le definizioni di deployment e le procedure di ripristino possono inoltre specificare versioni di Python o PostgreSQL e dovrebbero essere confrontate con i nuovi minimi. (mergebot.odoo.com)
La fonte stabilisce le versioni minime selezionate, ma non descrive tutte le condizioni di compatibilità per i sistemi operativi, i pacchetti Python, le estensioni PostgreSQL o i moduli Odoo di terze parti. (mergebot.odoo.com) Le organizzazioni dovrebbero quindi testare il proprio insieme reale di moduli e il design del deployment su Python 3.12 e PostgreSQL 15. Il rispetto dei requisiti minimi è un requisito della piattaforma, non la prova che ogni componente personalizzato o di terze parti sia compatibile. (mergebot.odoo.com)
Come adattare la pianificazione di Odoo 20
Un piano di readiness per Odoo 20 può suddividere il lavoro in tre flussi. Il primo è monitorare la documentazione pubblica della 20.0 e lo staging del branch per le modifiche rilevanti per i processi di business e la progettazione tecnica. Il secondo è spostare la migrazione del RPC legacy da un blocco alla rimozione in Odoo 20 a un lavoro di deprecazione pianificato da completare prima del punto di rimozione Odoo 21.1/22 indicato. Il terzo è convalidare l'infrastruttura rispetto ai requisiti minimi di Python 3.12 e PostgreSQL 15. (Odoo 20.0 Docs: eCommerce B2b B2c; Odoo pull Docs: 16925; mergebot.odoo.com; Runbot Merge)
Questo approccio evita due errori di pianificazione. Uno è rimandare tutta la preparazione perché queste fonti non stabiliscono un traguardo generale di rilascio. L'altro è considerare la documentazione pubblica e l'attività di staging come prova che tutte le funzionalità, le interfacce e i requisiti di deployment siano definitivi. Le fonti supportano il lavoro preparatorio, mentre l'approvazione finale dovrebbe dipendere dalla verifica rispetto alla release e all'ambiente di deployment selezionati. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
L'inventario RPC può procedere indipendentemente dalla decisione finale sul rilascio di Odoo 20, perché l'attuale posizione indica la continua disponibilità del servizio legacy e un punto di rimozione successivo. I team infrastrutturali possono inoltre identificare gli ambienti al di sotto di Python 3.12 o PostgreSQL 15 prima che il calendario della migrazione dell'applicazione sia fissato. (Odoo pull Docs: 16925; mergebot.odoo.com)
Controlli prima di approvare una migrazione
Prima di approvare una migrazione a Odoo 20, i responsabili delle decisioni dovrebbero verificare la build esatta in esame, la documentazione applicabile alle loro applicazioni e se le modifiche staged pertinenti sono state modificate durante la preparazione del rilascio. La documentazione pubblica della versione 20.0 e l'attività del branch mostrano progressi, ma non stabiliscono lo stato finale del rilascio. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Il processo di approvazione dovrebbe includere anche un elenco documentato delle dipendenze XML-RPC e JSON-RPC, un responsabile e un approccio di migrazione per ciascuna dipendenza, oltre a prove di test per ogni passaggio a JSON-2. Le integrazioni esistenti possono rimanere sui servizi deprecati in Odoo 20 e 21 secondo l'attuale posizione, ma il piano dovrebbe prevedere la rimozione in Odoo 21.1/22. (Odoo pull Docs: 16925)
Infine, i team dovrebbero confermare Python 3.12 e PostgreSQL 15 in tutti gli ambienti di produzione, non di produzione e di ripristino. I moduli personalizzati, i pacchetti esterni e le procedure operative dovrebbero essere testati su queste versioni, invece di essere considerati compatibili solo in base alla decisione sulla versione minima. (mergebot.odoo.com)
L'attuale posizione supporta una preparazione anticipata senza implicare che Odoo 20 sia definitivo: la documentazione pubblica e lo staging del branch sono disponibili per la consultazione, l'RPC legacy rimane deprecato ma disponibile tramite Odoo 20 e 21, e i requisiti minimi della piattaforma salgono a Python 3.12 e PostgreSQL 15. (Odoo 20.0 Docs: eCommerce B2b B2c; Odoo pull Docs: 16925; mergebot.odoo.com; Runbot Merge)