package migra

Changelog

All notable changes to this project are documented here. The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

1.0.0

First stable release.

Added

• Checksums & validation - each applied migration's file checksum is recorded; migrate refuses to run if an already-applied migration was modified (ChecksumMismatch) or its file went missing (AppliedFileMissing).
• Out-of-order detection - adding a migration older than the latest applied one is rejected (OutOfOrder).
• Configurable migrations table via --table / Migrator.make ~table.
• redo command and Migrator.redo - roll back the last migration(s) and re-apply.
• --dry-run for migrate and rollback - preview without changing the database.
• --database-url flag - overrides the DATABASE_URL environment variable.
• Library facade - Migra.Migrator (run/run_or_error/rollback/redo/status/generate, with ?on_event progress callbacks) and Migra.Database (lifecycle + URL helpers) form the public API; the implementation lives in the internal migra.engine library.
• Migra.Migrator.run_or_error - a fail-fast wrapper around run for the migrate-on-startup path: a migration whose SQL fails is returned as Error (MigrationError (ExecutionFailed ...)) rather than Ok with failure_count > 0.
• Arbitrary SQL support: dollar-quoted bodies, DELIMITER for MySQL/MariaDB routines, line/block comments, and literal $/? in statements.

Changed

• Credentials are masked (*****) in status output and never printed in clear.
• Stricter migration filenames: exactly 14 digits then _<description>.sql; malformed migration-shaped files are reported instead of silently skipped.
• Migrator.run/rollback return Error only when migrations could not run; per-migration SQL failures surface as Ok with failure_count > 0 (see Migrator.succeeded).

Fixed

• Connections are always closed (no leak), even on error paths.
• The admin connection URL preserves passwords, query parameters, and IPv6 hosts.
• Duplicate migration versions are detected and rejected.

Known limitations

• On MySQL/MariaDB, DDL statements implicitly commit and cannot be rolled back, so a multi-statement DDL migration is not atomic there. Keep MySQL/MariaDB migrations to a single DDL change each. (PostgreSQL and SQLite are fully transactional, including DDL.)