Skip to content

Roadmap

Items are tracked as GitHub issues. This page is a high-level overview.

Scope

pytest-mrt answers one question: will this migration's rollback actually restore the database, data included? Static detection and dynamic up/down/up verification are the two halves of that question, and every feature should be traceable back to it.

The feature surface is frozen (2026-09-28)

23 releases shipped in the 40 days after 2026-06-04, and not one of them started from a request made outside the project. That is how a rollback verifier came to own a file watcher, an AI explainer and six database backends. So new commands and new flags are on hold: a new feature needs someone outside the project to ask for it — an issue or a discussion, not an idea.

What continues as normal: bug fixes, supported-version updates (Python, Django, Alembic, SQLAlchemy), accuracy work on the rules that already exist, and documentation.

The precedent is v1.5.0, which removed mrt fix: generating migration code was a transform, and this tool verifies. Anything that cannot answer the question above is a candidate for the same treatment.

Shipped

v1.9.1 — Import hygiene

  • mrt starts about twice as fast: import pytest_mrt no longer pulls SQLAlchemy in through MRTTestCase, which now loads on first use. mrt --help went from 0.34s to 0.19s.
  • Function-local imports cut from 104 to 36; each remaining one states why it stays.

v1.9.0 — Correctness hardening

  • MRTTestCase.assertDataIntact() now quotes SQL identifiers, so reserved-word and mixed-case table names work.
  • All file reads state encoding="utf-8", so migrations containing non-ASCII text work off UTF-8 locales.
  • mrt check --since no longer skips descendants of migrations that use swappable_dependency.
  • mrt explain exits 1 on failure and takes --model. MRTConfig.explain_model is deprecated — it was never read.

v1.8.0 — Supported versions and toolchain

  • Python 3.14 declared and primary in CI; 3.15 runs as a non-blocking prerelease leg.
  • Django matrix moves to 5.2 LTS / 6.0 / 6.1; the django extra floor is >=4.2.
  • The postgres extra installs psycopg 3 alongside psycopg2, since SQLAlchemy 2.1 resolves a bare postgresql:// URL to psycopg 3.
  • CI services: PostgreSQL 18, MySQL 8.4 LTS, SQL Server 2025.

v1.7.0 — Django rolling-deploy compatibility

  • mrt check --check-compat now supports Django migrations (MRT701–MRT704), mapping RemoveField/RenameField/DeleteModel/RenameModel/AlterModelTable/AddField to the same rolling-deploy patterns as Alembic. MRT705 (type change) remains Alembic-only.

v1.6.0 — Fine-grained step control

  • upgrade_to(), upgrade_one(), downgrade_one(), downgrade_to(), current_revision() — test data migration logic at any intermediate point in the migration chain

v1.5.0 — Scope reduction

  • Removed mrt fix and mrt clean-backups — out of scope for a testing tool
  • Fixed RollbackVerifier false positive on failed custom seeds

v1.4.0 — CI integration + rolling deploy safety

  • mrt check --format json/html — structured output for CI pipelines and HTML safety reports
  • mrt check --watch — re-run on file change during development
  • mrt check --min-revision — skip revisions older than a configured floor
  • mrt check --check-compat — rolling-deploy compatibility checks (MRT701–MRT705)
  • Django squashmigrations detection — MRT601/MRT602
  • croc100/pytest-mrt-action v1.0.0 — GitHub Actions integration

v1.3.0 — Incremental CI + pre-commit

  • mrt check --since — scan only new migrations in PRs
  • pre-commit hook (.pre-commit-hooks.yaml)

v1.1.0–v1.2.0 — Default tests + rule codes

  • Six built-in default tests auto-injected on fixture configuration
  • Schema drift detection (mrt drift, assert_schema_matches())
  • MRT rule codes (MRT101–MRT902) and # noqa: MRTxxx suppression

v1.0.0 — Production/Stable

  • Full database coverage: PostgreSQL, SQLite, MySQL/MariaDB, Oracle, SQL Server
  • Full migration framework coverage: Alembic (static + dynamic) and Django (static + dynamic)
  • 44+ static analysis patterns, public accuracy report

Under consideration

Django squashmigrations: dynamic rollback testing

Static detection of squashmigrations is already in v1.4.0 (MRT601/MRT602). The next step is dynamic verification: run the rollback plan through the squashed migration graph and verify it succeeds. Currently skipped in check_all().

Per-pattern confidence scores

Add a confidence field to mrt check --format json output. Lets downstream tooling suppress known false-positive-prone patterns without using # noqa.

Click a finding in the HTML report to jump to the exact line in the migration file. Requires either embedding file contents or linking to the file on disk/GitHub.

Sentry integration

Report dynamic rollback failures as Sentry events, enabling production-side alerting when a migration that was not tested fails in the field.

What won't be in scope

  • Executing migrations in production (this is a testing tool only)
  • Migration code generation / auto-fix (removed in v1.5.0 — out of scope)
  • Schema diff tools (use alembic check or django-migration-linter)
  • ORM-agnostic support (focused on Alembic and Django)

How to influence the roadmap

Open an issue tagged roadmap with your use case. Sponsorship fast-tracks specific items — see GitHub Sponsors.