Odoo 正在以專用的 20.0 路徑發布使用者文件，而其官方合併基礎架構顯示，目標為 20.0 分支的準備工作正在進行。這些發展使 Odoo 20 文件與開發活動對外可見。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge) 這些內容並不表示一般發布日期已確認，也不代表每個功能、移轉需求與文件頁面都已定稿。組織應區分可見的準備工作與已確認的正式上線里程碑。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
Odoo 也已調整移除舊版 XML-RPC 與 JSON-RPC 服務的時程。移除現在延後至 Odoo 21.1/22，而 Odoo 20 與 21 會以棄用形式保留這些服務，並與 JSON-2 並存。 (Odoo pull Docs: 16925) 因此，使用舊服務的整合在升級到 Odoo 20 或 21 時，並不會面臨已確認的移除事件。不過，因為這些版本仍屬棄用狀態，仍需提前規劃，不能將其視為會無限期保留介面的承諾。 (Odoo pull Docs: 16925)
公開的 Odoo 20 活動確認了什麼
在 Odoo 的 20.0 文件結構中，至少有一個公開的使用者文件頁面可用。Odoo 的合併基礎架構也顯示 20.0 分支存在準備活動。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge) 這些來源可支援早期技術探索，但無法證明完整文件集已完成，也不能保證每一項準備中的變更都會不變地進入正式產品。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
團隊可以利用現有文件先檢視受影響的業務流程，並透過準備活動找出值得持續關注的開發區域。不過，移轉預算與交付日期仍應將後續對最終文件、受支援升級路徑，以及部署所選確切版本的驗證納入考量。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
這種區分有助於避免把公開文件路徑誤認為已完成發布的證據。現有來源確認 Odoo 20 相關資料與分支工作已可見，但並未提供完整的發布驗收清單。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
舊版 RPC 仍可用，但已棄用
原先預期在 Odoo 20 移除 XML-RPC 與 JSON-RPC 的計畫，應予以修正。目前的立場是將移除延後至 Odoo 21.1/22，並讓 Odoo 20 與 21 繼續提供這兩項舊服務。JSON-2 也可一併使用。 (Odoo pull Docs: 16925) 因此，組織可以重新評估那些僅為了避免 Odoo 20 停用而計畫的重寫作業的緊迫性，同時持續推動脫離已棄用介面的必要工作。 (Odoo pull Docs: 16925)
整合負責人應建立一份 XML-RPC 與 JSON-RPC 使用清單，涵蓋自訂程式碼、外部系統，以及由核心 Odoo 實作之外所管理的連線。接著可為每個相依項目指定負責人，在目標 Odoo 版本上進行測試，並評估是否可遷移至 JSON-2. (Odoo pull Docs: 16925) 由於移除時間點寫明為 Odoo 21.1/22，因此規劃應依據文件中的確切目標版本進行，而不是把該說法視為日曆上的截止日期. (Odoo pull Docs: 16925)
對於 Odoo 20 與 21，舊版 RPC 的使用屬於將被停用與未來移除的風險，而不是表示這些服務已確定不存在。升級測試仍應檢查驗證、請求處理、錯誤行為，以及各個整合所產生的業務結果. (Odoo pull Docs: 16925) 來源確認其與 JSON-2 並存，但並未說明每一個舊版呼叫都有完全相同的 JSON-2 對應，或遷移時不需要任何應用程式變更. (Odoo pull Docs: 16925)
延後提供了分階段遷移的額外時間，但不應被視為可忽略相依性的理由。實際可行的計畫可在 Odoo 20 或 21 升級期間維持現有整合，同時在所述移除時間點之前將其轉移至 JSON-2。若 Odoo 再次變更版本規劃，時程也應重新檢視. (Odoo pull Docs: 16925)
Python 與 PostgreSQL 最低版本提高
Odoo 已選定 Python 3.12 作為 Odoo 20 的最低 Python 版本，並選定 PostgreSQL 15 作為最低 PostgreSQL 版本. (mergebot.odoo.com) 這些需求應納入自管安裝與其他由組織控制應用程式或資料庫平台的環境就緒審查。低於任一最低版本的系統，必須先完成平台變更，才能視為符合所述的 Odoo 20 基準. (mergebot.odoo.com)
版本檢查應涵蓋開發、測試、預備、正式、備份還原，以及災難復原環境。建置映像、部署定義與復原程序也可能指定 Python 或 PostgreSQL 版本，並應對照新的最低版本進行審查. (mergebot.odoo.com)
來源已確立所選的最低版本，但未描述作業系統、Python 套件、PostgreSQL 擴充功能或第三方 Odoo 模組的所有相容性條件. (mergebot.odoo.com) 因此，組織應在 Python 3.12 與 PostgreSQL 15 上測試其實際模組組合與部署設計。符合最低版本只是平台要求，並不代表每個自訂或第三方元件都相容. (mergebot.odoo.com)
如何調整 Odoo 20 規劃
Odoo 20 的就緒計畫可將工作分成三個流程。第一個是監控公開的 20.0 文件與分支預備，找出與業務流程及技術設計相關的變更。第二個是把舊版 RPC 遷移，從 Odoo 20 的阻礙項改為排程中的停用工作，並在所述 Odoo 21.1/22 移除時間點之前完成。第三個是依據 Python 3.12 與 PostgreSQL 15 的最低版本驗證基礎架構. (Odoo 20.0 Docs: eCommerce B2b B2c; Odoo pull Docs: 16925; mergebot.odoo.com; Runbot Merge)
這種做法可避免兩種規劃錯誤。其一是因為這些來源沒有建立一般發佈里程碑，就延後所有準備。其二是把公開文件與預備活動視為所有功能、介面與部署需求都已定案的證明。這些來源支持前置作業，而最終核准應取決於對所選版本與部署環境的驗證. (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
RPC 清查可以獨立於 Odoo 20 最終發佈決策之外進行，因為目前立場明確指出舊版服務仍會持續可用，且會在較後時間才移除。基礎架構團隊同樣可以先找出低於 Python 3.12 或 PostgreSQL 15 的環境，無需等到應用程式遷移時程完全定案。 (Odoo pull Docs: 16925; mergebot.odoo.com)
遷移核准前的檢查
在核准 Odoo 20 遷移之前，決策者應確認正在評估的確切版本、適用於其應用程式的文件，以及相關的分階段變更是否在發佈準備期間被修改。公開的 20.0 文件與分支活動顯示了進展，但不能作為最終發佈狀態的依據。 (Odoo 20.0 Docs: eCommerce B2b B2c; Runbot Merge)
核准流程也應包含一份已記錄的 XML-RPC 與 JSON-RPC 相依項清單、每項相依項的負責人與遷移方式，以及任何轉移至 JSON-2 的測試證據。依照目前立場，既有整合可在 Odoo 20 與 21 中繼續使用已棄用的服務，但計畫應處理在 Odoo 21.1/22 的移除。 (Odoo pull Docs: 16925)
最後，團隊應在正式環境、非正式環境與復原環境中確認 Python 3.12 和 PostgreSQL 15。自訂模組、外部套件與作業程序應在這些版本上進行測試，而不是僅根據最低版本決定就假設相容。 (mergebot.odoo.com)
目前立場支持提早準備，同時不暗示 Odoo 20 已經定案：可檢視公開文件與分支分階段內容，舊版 RPC 仍屬棄用但在 Odoo 20 與 21 期間可用，而平台最低需求則提升至 Python 3.12 與 PostgreSQL 15。 (Odoo 20.0 Docs: eCommerce B2b B2c; Odoo pull Docs: 16925; mergebot.odoo.com; Runbot Merge)