Skip to main content

Upgrading

What a developer or server administrator needs to know when the modules or Odoo change: how the modules are versioned, how a database is updated, how to test an update on a copy, and what changes for integrations after the Odoo 18.0 series. The step-by-step update is on the Upgrade guide.

Module versions​

A module version has the form 18.0.x.y.z: 18.0 is the Odoo series, x.y.z the module's own version. The modules of this documentation are for Odoo 18.0: the core is at 18.0.0.2.0, the other five at 18.0.1.0.0 (the current versions are in the technical reference). Each version's changes are in the changelog, and the known issues in the release notes.

Updating a database​

A new version within the 18.0 series is installed by replacing the module folders on the server and updating the modules in the database, from Apps or with odoo-bin:

odoo-bin --addons-path=<odoo>/addons,<enterprise>,<rx-modules> -d <database> -u aglow_rx_tracking --stop-after-init

Updating the core updates every installed Rx Tracking module, since they all depend on it. Every record is kept; views, menus, access rules and data records are reloaded from the new files. The full procedure, and what an update sets back: Update the modules to a new version.

  • Migration scripts. The released 18.0 versions ship none: no update so far needs data to be converted. A version that needs it ships Odoo migration scripts in the module's migrations/<version>/ folder, which Odoo runs during the update, and its changelog entry and release notes say what they change.
  • Never uninstall to upgrade. Uninstalling a module deletes its records, including the DSCSA documents, the package ledger and the licenses, and reinstalling it brings nothing back (Uninstall a module, and what is deleted with it).
  • Your own modules that extend ours: read the changelog for the extension points you use, update them together with ours, and run their tests and the contract tests after the update.

Test the update on a copy​

Try every update on a copy of the production database first, then run the modules' test suites on a new database (Testing).

Neutralize the copy. A copy that still has production's settings can act like production: send emails, run scheduled jobs, and write into production's off-site archive, where Object Lock keeps what it receives for years. Make the copy with Odoo's neutralize option (the Neutralize checkbox when you duplicate or restore a database in the database manager, or odoo-bin neutralize -d <copy>; Odoo.sh neutralizes its staging databases itself). Besides Odoo's own neutralization, the core module then switches the off-site archive off and deletes the stored archive secret key in the copy, so a copy never reaches the archive. See A copy of the database still has the archive on.

The external API after Odoo 18​

The External API recipes use XML-RPC and JSON-RPC, which Odoo 18 provides. Odoo has announced changes after 18.0, in its External API documentation for 19.0:

  • Odoo 19 adds the JSON-2 API: POST /json/2/<model>/<method>, with the API key sent as a bearer token in the Authorization header, and one database transaction per call.
  • XML-RPC and JSON-RPC are deprecated from Odoo 19. The endpoints /xmlrpc, /xmlrpc/2 and /jsonrpc are scheduled for removal in Odoo 22 (planned by Odoo for fall 2028). An integration built on the recipes of this documentation needs to move to JSON-2 before its database moves to Odoo 22.
  • For module code, Odoo 19 renames the controller route type type='json' to type='jsonrpc'.

The API keys, access rights and public methods described here are what JSON-2 works with too: it calls a model's public methods as the user the key belongs to.

Moving to another Odoo series​

Moving a database from Odoo 18.0 to a later series is Odoo's own database upgrade, followed by the Rx Tracking modules made for that series; the 18.0 modules don't install on another series. Which series this documentation covers is on Versions. Odoo's procedure: Upgrade documentation.