Nothing you have installed changes. This release is about the two moments the
multi-instance work of 3.1.0 and 3.2.0 had left uncomfortable — the helper, and
the moment you create a second instance — plus the one Odoo × distribution
combination that did not work.
Leaving dev no longer leaves an instance down
dev stops the service and opens a shell as the instance's user. It used to
leave it stopped, saying so in a line that only whoever was still watching the
screen ever read. Now it puts the service back the way it found it:
Restart 'odoo18'? [Y/n]
You are asked first, and the answer you get by pressing Enter is always as it
was — an instance that was serving comes back up, one you had deliberately
switched off stays off. Close the window, or kill the session, and the same rule
is applied without asking: that is the case the behaviour exists for, and a
question needs somebody there to answer it.
Three verbs can name another instance
status, logs and dev take an instance, so you can go from list to what
you meant without first remembering somebody else's helper name:
odoo list # what is here, what is up, what drives each
odoo status cliente-x
odoo logs cliente-x 500
odoo dev cliente-x # a shell as its user, to reach its filesNames work the way list prints them — cliente-x, odoo-cliente-x,
odoo-cliente-x.service — plus default for the unnamed installation. An
unknown name is refused with the listing; a name matching two installations is
refused rather than guessed.
start, stop and restart do not take one, and that is a choice rather
than an omission: looking at somebody else's instance is not the hazard,
starting it is. To act on a named instance you use its own helper, which list
tells you. For the same reason dev cliente-x opens a shell without stopping
that service — and says so, since its port stays busy.
The form asks which instance this is
Until now an instance could only be created with --instance or
ODOO_INSTANCE, so whoever sat at the terminal learned a second Odoo was
possible from a refusal, after the fact. Run sudo invok with no arguments and
the first question is now:
? Instance name (empty = the historical instance)
a second Odoo beside an existing one needs a name; leave empty for the first
Leaving it empty is a real answer and changes nothing. It is the first
question because everything below it is named after it: the user, the database
and the install directory are then suggested as odoo-cliente-x instead of
odoo.
Odoo 16 installs on Fedora
It did not, and the reason was upstream: Odoo 16's newest gevent pin is
written for Python >= 3.12 with nothing above it, so past 3.12 pip kept
choosing a release whose newest prebuilt wheel is cp312 and had to compile.
The ceiling the installer applies is now per Odoo version — 3.12 for 16,
3.13 for the rest — so on Fedora it installs python3.12 for the occasion,
builds the virtualenv on it, and the rollback takes it back with everything
else. Ubuntu and Debian are unaffected: their system Python was already below
both ceilings.
This removes a declared limitation: the README, the package's own page and
two wiki pages said the combination did not work. A CI job now installs and
rolls it back on fedora:41, and a test refuses to let a version with a ceiling
of its own exist without such a job.
Upgrading
Download the new version and replace the binary; there is no repository to
update. Installed instances are untouched — their manifests, services and
helpers keep working, and the helper in your home is rewritten with the new
verbs the next time you install anything on that machine.