Odoo 19.0: one dependency set for ten apps and no release tag

Ten apps, one dependency list

The app list is presented as a growth path: Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, and Manufacturing. Each can be used as a stand-alone application, and the full ERP appears when several are installed together. What the repository shows is that the unit of installation is not the app. addons/ holds the apps, but setup.py declares one install_requires block for the package, so the dependency surface is the same whether you run a CRM or a factory floor.

    install_requires=[
        'asn1crypto',
        'babel >= 1.0',
        'cbor2',
        'chardet',

Spreadsheet libraries (xlrd, xlsxwriter, openpyxl), a PDF library (pypdf), a SOAP client (zeep), serial and USB bindings (pyserial, pyusb), and an OFX file parser (ofxparse) are unconditional entries. They arrive even for a deployment that never opens those formats, so the consequence for a reader is direct: you cannot trim an install down to the one app you actually need.

setup.py reads its own version out of odoo/release.py

setup.py has no version literal. It runs exec(open(join(dirname(__file__), 'odoo', 'release.py'), 'rb').read()) to load release variables, then hands version, description, long_desc, url, author, author_email, classifiers, and license to setup(). The file carries a comment noting that ruff does not see read variables from release.py, and its header is marked ruff: noqa: F821, which is a lint escape hatch for exactly this pattern. Two consequences follow. First, the version a build reports is decided by a data file inside the tree, so a build number cannot be recovered from a tag name. Second, the license string published to package indexes also comes from that file, while this repository's license is reported as NOASSERTION, so automated license scanners have nothing machine readable to resolve. LICENSE and COPYRIGHT at the top level are the only place the terms are stated.

requirements.txt keys every pin to a distro Python build

The header comment sets the policy: officially supported versions of these packages are their python3-* equivalent distributed in Ubuntu 24.04 and Debian 12. Most lines then split on python_version, and the trailing comments name the distro release that supplied the build, such as Noble, Trixie and Resolute. The file is a lookup table with one row per Python minor version, not a floor.

asn1crypto==1.5.1 ; python_version >= '3.11'
cbor2==5.6.2 ; python_version >= '3.12'
cryptography==42.0.8 ; python_version >= '3.12'  # (Noble) min 41.0.7, pinning 42.0.8 for security fixes

Consequence: a reader who strips the markers and treats the numbers as minimums ends up with a dependency set nobody tested.

cryptography is held back for a pyopenssl reason

The cryptography row carries its reasoning inline: for python_version >= '3.12' it pins cryptography==42.0.8, annotated "(Noble) min 41.0.7, pinning 42.0.8 for security fixes". setup.py, by contrast, lists cryptography and pyopenssl with no version constraint at all.

setup.py and requirements.txt disagree about gevent on Windows

setup.py lists gevent and greenlet in install_requires with no platform marker at all. requirements.txt wraps every gevent and greenlet pin in sys_platform != 'win32', and splits gevent by interpreter: 24.2.1 from 3.12 to below 3.13, and 24.11.1 from 3.13. greenlet steps 3.0.3, 3.1.1, and 3.3.2 the same way. Two files, two answers, and neither names the other as the authority. The consequence is a Windows install that resolves gevent from packaging metadata where the requirements file would have skipped it entirely, and a reader reconciling the two has to spot the gap by hand. The README's getting started section does not say which file an installation is meant to read.

The top level has debian/ and no install recipe

The top level is a packaging skeleton, not a procedure: addons/, debian/, doc/, odoo-bin, odoo/, requirements.txt, ruff.toml, setup.cfg, setup.py, setup/, plus .github/, .weblate.json, CONTRIBUTING.md, COPYRIGHT, LICENSE, MANIFEST.in, README.md, SECURITY.md. setup.py installs a console entry from scripts=['setup/odoo']. The only route to an actual installation is a link out to the Setup instructions page at odoo.com/documentation/master/administration/install/install.html, with the developer tutorials, Odoo eLearning, and the Scale-up business game offered for learning the software. Consequence: the repository cannot bootstrap itself, and the recipe you follow lives in documentation that can change independently of branch 19.0. If your install has to be auditable, snapshot that page alongside your commit.

Branch 19.0 with no GitHub releases behind it

The default branch is 19.0, and the repository has no GitHub releases. There is no release asset to pin a build against, and the recorded push date is 2026-11-02. Paired with a version string that lives in odoo/release.py rather than in a tag, reproducibility has to come from your own mirror, a vendored copy, or a hosted build. The linked routes for the surrounding work are Runbot, the documentation master index, the help forum, and nightly.odoo.com. Security reports go to a Responsible Disclosure page at odoo.com/security-report rather than the public issue tracker, with SECURITY.md at the top level. Consequence for a reader: expect disclosure by email, and expect to identify a running system by the version it prints, since there is no downloadable artifact here to hash.

Nothing in the tree covers upgrade or rollback

What the top level lacks is as telling as what it holds. The README's getting started section covers no migration, upgrade or rollback procedure. For a suite whose stated value is running CRM, inventory, accounting, and Point of Sale against one database, that is the gap a reader has to close somewhere else. Before adopting, pin the branch you build from, record the version string the build reports, and treat the Setup instructions page as documentation you have to version yourself.

Editorial conclusion

Read this branch as a source tree, not as a product decision. Teams that need one app should confirm first that a single install pulls the whole dependency list. Before committing, check LICENSE and COPYRIGHT for the actual terms, snapshot the Setup instructions page you rely on, and identify builds by the version string in odoo/release.py, because the repository publishes no releases to pin against.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository