Odoo publică documentația pentru utilizatori pe o rută dedicată 20.0, iar infrastructura sa oficială de merge arată activitate de staging pentru ramura 20.0. Aceste evoluții fac vizibile public documentația Odoo 20 și activitatea de dezvoltare. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge) Acestea nu confirmă o dată generală de lansare și nici faptul că fiecare funcționalitate, cerință de migrare și pagină de documentație este finală. Organizațiile ar trebui să distingă între pregătirea vizibilă și un moment confirmat al lansării în producție. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Odoo a schimbat și calendarul pentru eliminarea serviciilor sale vechi XML-RPC și JSON-RPC. Eliminarea este acum amânată până la Odoo 21.1/22, în timp ce Odoo 20 și 21 păstrează serviciile într-o formă depreciată, alături de JSON-2. (Odoo pull Docs: 16925) Prin urmare, integrările care folosesc serviciile mai vechi nu se confruntă cu un eveniment confirmat de eliminare la actualizarea la Odoo 20 sau 21. Totuși, deprecierea necesită planificare, deoarece disponibilitatea în aceste versiuni nu reprezintă un angajament de păstrare a interfețelor pe termen nelimitat. (Odoo pull Docs: 16925)
Ce confirmă activitatea publică Odoo 20
Cel puțin o pagină publică de documentație pentru utilizatori este disponibilă în structura de documentație 20.0 a Odoo. Infrastructura de merge a Odoo indică, de asemenea, activitate de staging pentru ramura 20.0. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge) Aceste surse pot sprijini descoperirea tehnică timpurie, dar nu stabilesc că întregul set de documentație este complet sau că fiecare schimbare din staging va ajunge în producție neschimbată. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Echipele pot folosi documentația disponibilă pentru a începe revizuirea proceselor de business afectate și activitatea din staging pentru a identifica zonele de dezvoltare care merită monitorizate. Bugetele de migrare și datele de livrare ar trebui totuși să includă verificări ulterioare față de documentația finală, calea de upgrade suportată și buildul exact selectat pentru implementare. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Această distincție ajută la evitarea tratării unei rute publice de documentație ca dovadă a unei lansări finalizate. Sursele disponibile confirmă că materialele și activitatea pe ramură Odoo 20 sunt vizibile, dar nu oferă o listă completă de acceptare pentru lansare. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
RPC vechi rămâne disponibil, dar depreciat
Planurile bazate pe eliminarea așteptată a XML-RPC și JSON-RPC în Odoo 20 ar trebui revizuite. Poziția actuală amână eliminarea până la Odoo 21.1/22 și păstrează ambele servicii vechi disponibile în Odoo 20 și 21. JSON-2 este disponibil alături de ele. (Odoo pull Docs: 16925) Organizațiile pot, prin urmare, să reevalueze urgența rescrierilor planificate exclusiv pentru a evita o întrerupere în Odoo 20, continuând în același timp lucrările necesare pentru a trece de la interfețele depreciate. (Odoo pull Docs: 16925)
Responsabilii integrărilor ar trebui să creeze un inventar al utilizării XML-RPC și JSON-RPC în codul personalizat, sistemele externe și conexiunile gestionate în afara implementării de bază Odoo. Fiecare dependență poate fi apoi atribuită unui responsabil, testată pe versiunea țintă de Odoo și evaluată pentru migrare la JSON-2. (Odoo pull Docs: 16925) Deoarece punctul de eliminare este menționat ca Odoo 21.1/22, planificarea ar trebui să urmeze documentația pentru versiunea țintă exactă, nu să trateze acea formulare ca pe un termen limită calendaristic. (Odoo pull Docs: 16925)
Pentru Odoo 20 și 21, utilizarea RPC vechi reprezintă un risc de depreciere și de eliminare viitoare, nu o absență confirmată a serviciilor. Testarea upgrade-ului ar trebui să examineze în continuare autentificarea, gestionarea cererilor, comportamentul erorilor și rezultatele de business produse de fiecare integrare. (Odoo pull Docs: 16925) Sursa confirmă coexistența cu JSON-2, dar nu afirmă că fiecare apel vechi are un echivalent JSON-2 identic sau că migrarea nu va necesita modificări ale aplicației. (Odoo pull Docs: 16925)
Amânarea creează timp suplimentar pentru migrarea etapizată, dar nu ar trebui tratată ca motiv pentru a lăsa dependențele nedocumentate. Un plan practic poate menține integrările existente în timpul unui upgrade la Odoo 20 sau 21, mutându-le la JSON-2 înainte de punctul de eliminare menționat. Calendarul ar trebui revizuit dacă Odoo își modifică din nou planurile de versiune. (Odoo pull Docs: 16925)
Minimele pentru Python și PostgreSQL cresc
Odoo a ales Python 3.12 ca versiune minimă de Python pentru Odoo 20 și PostgreSQL 15 ca versiune minimă de PostgreSQL. (mergebot.odoo.com) Aceste cerințe trebuie incluse în evaluările de pregătire pentru instalațiile administrate intern și alte medii în care organizația controlează platforma aplicației sau a bazei de date. Sistemele sub oricare dintre minime vor necesita modificări de platformă înainte de a putea fi evaluate în raport cu baza de referință Odoo 20 menționată. (mergebot.odoo.com)
Verificările versiunilor ar trebui să acopere mediile de dezvoltare, testare, staging, producție, restaurare din backup și recuperare în caz de dezastru. Imaginile de build, definițiile de implementare și procedurile de recuperare pot specifica, de asemenea, versiuni de Python sau PostgreSQL și ar trebui verificate în raport cu noile minime. (mergebot.odoo.com)
Sursa stabilește versiunile minime alese, dar nu descrie toate condițiile de compatibilitate pentru sistemele de operare, pachetele Python, extensiile PostgreSQL sau modulele Odoo terțe. (mergebot.odoo.com) Prin urmare, organizațiile ar trebui să testeze setul lor real de module și designul de implementare pe Python 3.12 și PostgreSQL 15. Respectarea versiunilor minime este o cerință de platformă, nu o dovadă că fiecare componentă personalizată sau terță parte este compatibilă. (mergebot.odoo.com)
Cum să ajustați planificarea pentru Odoo 20
Un plan de pregătire pentru Odoo 20 poate separa munca în trei fluxuri. Primul este monitorizarea documentației publice 20.0 și a etapei de staging a ramurii pentru schimbări relevante pentru procesele de business și designul tehnic. Al doilea este mutarea migrației RPC vechi dintr-un blocant al eliminării în Odoo 20 într-o activitate de depreciere programată, finalizată înainte de punctul de eliminare Odoo 21.1/22 menționat. Al treilea este validarea infrastructurii în raport cu minimele Python 3.12 și PostgreSQL 15. (Odoo 20.0 Docs: eCommerce B2b B2c; Odoo pull Docs: 16925; mergebot.odoo.com; Runbot Merge)
Această abordare evită două erori de planificare. Una este amânarea tuturor pregătirilor deoarece aceste surse nu stabilesc un jalon general de lansare. Cealaltă este tratarea documentației publice și a activității de staging drept dovadă că toate funcționalitățile, interfețele și cerințele de implementare sunt finale. Sursele susțin munca pregătitoare, în timp ce aprobarea finală ar trebui să depindă de verificarea în raport cu lansarea și mediul de implementare selectate. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Inventarul RPC poate continua independent de decizia finală de lansare Odoo 20, deoarece poziția actuală indică menținerea disponibilității serviciului legacy și un moment ulterior de eliminare. Echipele de infrastructură pot, de asemenea, identifica mediile sub Python 3.12 sau PostgreSQL 15 înainte ca programul de migrare al aplicației să fie stabilit. (Odoo pull Docs: 16925; mergebot.odoo.com)
Verificări înainte de aprobarea unei migrări
Înainte de a aproba o migrare la Odoo 20, factorii de decizie ar trebui să verifice build-ul exact aflat în discuție, documentația aplicabilă aplicațiilor lor și dacă modificările relevante din staging au fost schimbate în timpul pregătirii lansării. Documentația publică 20.0 și activitatea din branch arată progres, dar nu stabilesc statutul final al lansării. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Procesul de aprobare ar trebui să includă, de asemenea, o listă documentată a dependențelor XML-RPC și JSON-RPC, un responsabil și o abordare de migrare pentru fiecare dependență, precum și dovezi de testare pentru orice trecere la JSON-2. Integrările existente pot rămâne pe serviciile depreciate în Odoo 20 și 21, conform poziției actuale, dar planul ar trebui să abordeze eliminarea lor în Odoo 21.1/22. (Odoo pull Docs: 16925)
În final, echipele ar trebui să confirme Python 3.12 și PostgreSQL 15 în mediile de producție, non-producție și recuperare. Modulele personalizate, pachetele externe și procedurile operaționale ar trebui testate pe aceste versiuni, nu presupuse compatibile doar pe baza deciziei privind versiunea minimă. (mergebot.odoo.com)
Poziția actuală susține pregătirea timpurie fără a implica faptul că Odoo 20 este final: documentația publică și staging-ul branch-urilor sunt disponibile pentru revizuire, RPC legacy rămâne depreciat, dar disponibil prin Odoo 20 și 21, iar minimele platformei cresc la Python 3.12 și PostgreSQL 15. (Odoo 20.0 Docs: eCommerce B2b B2c; Odoo pull Docs: 16925; mergebot.odoo.com; Runbot Merge)