Weblate Migration Reversibility: Absence of Formal Downgrade Support Policy

Question

ContextWeblate relies on Django's migration framework for schema changes, splitting operations into schema and data migrations. While schema migrations are generally reversible, data migrations using RunPython or RunSQL require explicit reverse_code to support rollback. The official upgrade documentation recommends database backups before upgrades and states that downgrades are not officially supported; rollback typically means restoring from backup rather than running reverse migrations.ConstraintsRelease notes for major versions (4.0, 4.11, 5.0) highlight migration complexity requiring manual steps, indicating automatic rollback safety is not guaranteed. CI runs migration tests on PostgreSQL, MySQL, and SQLite, but full downgrade path coverage (apply then reverse all migrations) is not documented as a release gating criterion. Container images and Helm charts assume forward-only upgrades; rolling back a container without database restore leaves the schema at a newer version.Open QuestionsWill Weblate adopt a formal downgrade support policy that marks migrations as reversible and provides rollback scripts?Are there plans to add downgrade path testing to the CI pipeline as a release gate?Should data migrations lacking reverse_code be flagged as blocking automatic rollback in the migration planner?

Zoha · Answer

Answer
Weblate does not have a formal downgrade support policy; rollback is performed by restoring a pre‑upgrade database backup and redeploying the previous Weblate release, not by running reverse migrations.

Confirmed Facts

The upgrade documentation for Weblate versions 4.0, 4.11 and 5.0 recommends a database backup before upgrading and states that downgrades are not officially supported.
Django’s migration framework only reverses a migration when every operation includes a reverse_code; data migrations using RunPython or RunSQL without a defined reverse are treated as irreversible.
Release notes for major releases mention manual migration steps and do not list automatic rollback as a gating criterion.
CI pipelines test migrations on PostgreSQL, MySQL and SQLite but do not include a full “apply‑then‑reverse” downgrade test as a release gate.
Container images and Helm charts assume forward‑only upgrades; rolling back a container without database restore leaves the schema at a newer version than the application code.

Likely Explanation
Because data migrations often lack a reversible implementation and full reverse‑path testing across multiple database back‑ends adds significant maintenance burden, Weblate has not defined a formal downgrade policy or CI downgrade gate. Consequently, automatic rollback is not guaranteed, and the recommended safe practice is backup‑restore‑redeploy.

Steps for This Case

Identify the Weblate version and the database backend (PostgreSQL, MySQL, or SQLite) you are using.
Take a full database backup before performing the upgrade.
Inspect the migration files for the target version and verify that any RunPython or RunSQL data migrations include a reverse_code. If they do not, automatic rollback is impossible.
Proceed with the upgrade as documented.
If you need to roll back, restore the backup taken in step 2 and redeploy the previous Weblate release (container image or Helm chart) that matches the backed‑up schema.

Diagnostic Detail Needed
Which Weblate version and database backend are you using?

Weblate Migration Reversibility: Absence of Formal Downgrade Support Policy

Context

Constraints

Open Questions

1 answer

Answer

Confirmed Facts

Likely Explanation

Steps for This Case

Diagnostic Detail Needed

Your perspective belongs here.

0 question comments