v3.2.0 — Odoo 16 installs, and every version we promise is now actually run

Nothing new to type, and nothing to migrate: existing installations are
untouched and the manifest format is unchanged. This release is about a
promise the front page has made since the beginning — Odoo 16, 17, 18 and
19 — that nothing had ever checked.

Odoo 16 installs again

It did not, and the cause was ours rather than Odoo's. The installer put
setuptools into the virtualenv without an upper bound — meaning whatever
exists today — and setuptools 82 removed pkg_resources, which Odoo 16
imports on its very first line. On Ubuntu 22.04 the virtualenv already ships
a setuptools that has it, so the installer was replacing a working one with a
broken one.

What that step owes the virtualenv is that setuptools exists, never that
it is the newest. It is now bounded.

All four versions are now exercised, not just accepted

Every CI configuration installed 18.0, so 16, 17 and 19 were accepted by the
command line and run by nobody — until a customer's machine reported the
first one. Each of the four now has a job that installs it, checks Odoo
answers over HTTP, and rolls it back, on both Ubuntu 22.04 and 24.04. A test
refuses to let the command line accept a version no job covers, so this
cannot quietly come back.

The other three, it turned out, already worked. They were not broken; they
were unverified — a different problem with the same cure.

One combination is declared instead of promised

Odoo 16 does not install on Fedora ≥ 41. Its newest gevent pin is
written for Python ≥ 3.12 and selects a release with no prebuilt wheel for
Python 3.13, which is the interpreter every current Fedora ends up on. That
is upstream's shape, not something the installer can flag away — but trying
it is no longer a wall of compiler output: the failure names the interpreter
and prints the pins that Odoo version declares.

Odoo 16 on Ubuntu or Debian is unaffected, and 17, 18 and 19 install on
Fedora normally.

Multi-instance: a failed installation no longer takes its neighbours down

If an installation fails halfway, the automatic cleanup now knows the
shared-artifact rule that invok rollback has known since 3.1.0. It matters
in one narrow case and only there: an instance that created /opt/odoo, the
system packages and the PostgreSQL cluster, was interrupted, had a second
instance installed beside it, and then failed on being resumed. It would have
removed them from under a running instance.

Related: when a rollback keeps the traversal bit on /opt/odoo because
another named instance still needs to walk through it, it now says so and
names who. Before, a changed permission was left with nothing to attribute it
to.

Also

• the explanation for a failed gevent build used to appear only on a Python
  newer than the ones tested — and the case it was written for happens on
  exactly the newest tested one, so it was silent precisely where it was
  needed;

Also

• the explanation for a failed gevent build used to appear only on a Python
  newer than the ones tested — and the case it was written for happens on
  exactly the newest tested one, so it was silent precisely where it was
  needed;
• the refusal that protects a PostgreSQL cluster whose PGDATA was moved by a
  drop-in is now exercised by a real job, not only by unit tests;
• a CI defect worth naming because it hid others: the Fedora jobs had never
  uploaded an installer log, and three separate "be quiet on failure" settings
  made sure nobody noticed.

Install or update

Download again from the assets below and verify the checksum — the commands,
with the exact file names, are in the README. There is no
apt/dnf repository to add. cargo install invok also gives 3.2.0.