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

> Odoo's default 19.0 branch ships a single Python package whose setup.py declares one dependency list for all ten apps, while requirements.txt pins versions per Ubuntu and Debian Python build. The install procedure lives in a documentation page, not in the tree, and no GitHub release sits behind the branch.

**odoo/odoo** — Odoo bundles CRM, eCommerce, accounting, warehouse and HR tools as web-based open source apps that combine into a full-featured ERP.

- Repository: https://github.com/odoo/odoo
- Website: https://www.odoo.com
- Stars: 54,687 · Forks: 33,839
- Language: Python
- License: not declared
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/odoo-odoo

## 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 writers (xlrd, xlwt, xlsxwriter, openpyxl), a PDF library (PyPDF2), a SOAP client (zeep), serial and USB bindings (pyserial, pyusb), and finance file parsers (ofxparse, vobject) 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. Every line then splits on python_version, and the trailing comments name the distro release that supplied the build, Jammy, Bookworm, Noble, Trixie. The file is a lookup table with one row per Python minor version, not a floor.

```
asn1crypto==1.4.0 ; python_version < '3.11'
asn1crypto==1.5.1 ; python_version >= '3.11'
cbor2==5.4.6 ; python_version >= '3.11' and python_version < '3.12'  # (Bookworm)
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. cbor2 alone steps from 5.4.2.post1 to 5.4.6 to 5.6.2 as the interpreter moves, and an interpreter your platform team has just standardized on has no row to land in.

## cryptography is held back for a pyopenssl reason

Two rows carry the reasoning inline. The cryptography==3.4.8 line for python_version < '3.12' is annotated as an incompatibility between pyopenssl 19.0.0 and cryptography>=37.0.0, and the newer row records min 41.0.7 with a note that 42.0.8 is pinned for security fixes. Read that against setup.py, which lists pyopenssl with no version constraint whatsoever, and the picture is a distribution frozen to keep one specific pyopenssl pairing workable. The consequence for a reader is concrete: on Python 3.11 and older this install will not bring a current cryptography, and no marker row exists that would let it move, so upgrading means editing the pin by hand. A scanner flagging an old cryptography on an older interpreter is reporting the intended state, not drift.

## 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 four ways by interpreter: 21.8.0 on 3.10, 22.10.2 above 3.10 and below 3.12, 24.2.1 from 3.12 to below 3.13, and 24.11.1 from 3.13. greenlet steps 1.1.2, 2.0.2, and 3.0.3 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'], and the Debian directory is the one place a machine readable recipe exists. Nothing points you at it. 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-09-26. 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. There is no migration guide, no documented upgrade path between version lines, and no rollback procedure, and the README's getting started section covers none of the three. 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. The apps are designed to be installed together, which means a single bad module install reaches the shared core, and the repository offers no documented way back from that. 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.

## 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, and anyone auditing cryptography on Python 3.11 or older should expect a deliberately old pin. 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.

## FAQ

### What exactly does Odoo do?

It is a suite of web based open source business apps, named in the repository as Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, and Manufacturing.

### what is odoo used for

The named apps cover CRM, websites, eCommerce, warehouse management, projects, billing and accounting, point of sale, human resources, marketing, and manufacturing, and the suite is described as a full ERP once several apps are installed together.

### Is Odoo free or paid?

The repository presents open source apps, and its license field is reported as NOASSERTION, with LICENSE and COPYRIGHT at the top level as the only stated terms. The getting started section routes a standard installation to the Setup instructions page on odoo.com rather than listing editions or plans.

### why is odoo free

The repository states only that Odoo is a suite of web based open source business apps, and it does not account for an edition structure, a community versus enterprise split, or a hosted pricing model. Those details are not in the source tree.

### is odoo reliable

The verifiable signals in the repository are a push dated 2026-09-26 on default branch 19.0, no GitHub releases, dependency pins resolved per Ubuntu 24.04 and Debian 12 Python builds, and a standard installation path that is a documentation page instead of an in-repo recipe.

### difference between odoo and erp

Odoo is framed as apps that work as stand-alone applications and add up to a full-featured open source ERP when several are installed, so the suite and the ERP are two descriptions of the same repository rather than two products.

## Sources

- [Official documentation](https://www.odoo.com)
- [Official README](https://github.com/odoo/odoo#readme)
- [Project repository](https://github.com/odoo/odoo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/odoo-odoo