The School Management System targets Odoo 19.0 exclusively. Future majors (20.0+) will likely require changes to our modules — _sql_constraints patterns, RelaxNG schemas, and portal templates all evolve release to release.
Minor Odoo releases (19.0.1, 19.0.2, ...) ship via the Docker image tag odoo:19.0. You're already on it if your docker-compose.yml references odoo:19.0. To pick up a minor:
docker compose pull odoo
docker compose up -d odoo
The running container restarts onto the newer image. No DB migration needed for minors; Odoo auto-updates the schema on boot if the release included schema tweaks.
Don't do this blindly. The upgrade checklist:
Odoo publishes breaking changes at https://www.odoo.com/documentation/20.0/. Scan for:
res.partner, hr.employee, account.move, product.template, stock.picking, calendar.event, mail.template, base.automation).Our Odoo 19 specifics doc lists every Odoo 19 pattern we rely on. Check each against the 20.0 docs.
# Backup prod first (see backup-and-restore doc)
DB_UPGRADE=school_upgrade_test
cp $BACKUP/school_prod.dump /tmp/
# ... restore into DB_UPGRADE ...
# Bump to 20 image
sed -i.bak 's/odoo:19.0/odoo:20.0/g' docker-compose.yml
docker compose pull odoo
# Run upgrade
docker compose run --rm --no-deps odoo odoo \
-d "$DB_UPGRADE" -u all --stop-after-init
-u all runs migrations for every installed module. Odoo writes upgrade logs to the container's stdout — capture them and grep for ERROR / WARNING.
Expect each school_* module to need edits. Typical surface:
__manifest__.py — bump version to 20.0.x.y.z._inherit target still exists with the same field names. Rename anywhere Odoo renamed.<list> / <tree> / decoration attrs may have changed.res.groups.privilege might be restructured again. Check.t-out / {{ }} rendering.base.automation trigger types evolve.Run each module's test suite as you go:
docker compose run --rm --no-deps odoo odoo \
-d "$DB_UPGRADE" -u school_base --test-enable \
--test-tags=/school_base --stop-after-init
Repeat for every school module.
Spot-check each major flow on the upgraded DB:
/my/school → shows correct data for a guardian portal user./ → stats display correctly.Only when the upgrade DB passes all regression tests:
school_prod → school_prod_old and the upgraded one to school_prod).docker-compose.yml to the new image tag.school_prod_old for ~30 days in case you need to roll back.Once you're confident in the upgraded DB (usually after a month), drop the backup:
docker compose exec -e PGPASSWORD=$POSTGRES_PASSWORD -T db \
dropdb -U odoo school_prod_old
If the upgrade goes sideways mid-flight, you have three options:
ALTER DATABASE school_prod RENAME TO school_prod_broken; ALTER DATABASE school_prod_old RENAME TO school_prod; — restore service in 30 seconds.docker-compose.yml to odoo:19.0, docker compose up -d.Always have a tested rollback path before you start the upgrade.