Upgrading Simple Aircraft Manager¶

v0.9 → v1.0¶

v1.0 replaces the incremental migration history with a single consolidated initial migration per app. The database schema is unchanged — only the migration files on disk are different. Because the schema does not change, rolling back to v0.9 is safe if something goes wrong.

If you are running a pre-v0.9 development build, you must upgrade to v0.9 first and confirm all migrations are applied before proceeding to v1.0. Jumping directly from an older dev build to v1.0 will likely fail because the consolidated 0001_initial migrations assume the full v0.9 schema is already present.

Back up your database before upgrading. The steps below are low-risk, but a backup is always good practice before any release upgrade.

Running management commands¶

The manage.py commands below must be run inside the application. How you do that depends on your deployment:

Local / venv: run the commands directly in your activated virtualenv.
Docker / Podman: docker exec -it <container-name> python manage.py <command>
OpenShift / Kubernetes: oc exec deploy/sam -n sam -- python manage.py <command>

Step 1 — Verify you are fully migrated on v0.9¶

While still running v0.9, confirm every migration has been applied:

python manage.py showmigrations core health

All entries should show [X]. Example of expected output:

core
 [X] 0001_initial
 [X] 0002_...
 ...
 [X] 0014_aircraftfeature
health
 [X] 0001_initial
 [X] 0002_...
 ...
 [X] 0031_...

If any entry shows [ ], run python manage.py migrate with the v0.9 image to apply the outstanding migrations before proceeding. Skipping this will cause the v1.0 application to fail with schema errors on every request.

Step 2 — Upgrade to v1.0¶

Pull and start the v1.0 image as you normally would, then run:

python manage.py migrate

Because the schema is unchanged, this produces no work to do. Expected output:

No migrations to apply.

Step 3 — Confirm the new migration state¶

python manage.py showmigrations core health

Expected output after the upgrade:

core
 [X] 0001_initial
health
 [X] 0001_initial

Only the single consolidated initial migration should appear per app. If you see this, the upgrade is complete.

Cleaning up orphan migration entries (optional)¶

The django_migrations table still contains the old numbered entries from v0.9. Django ignores them entirely — they do not appear in showmigrations output — so leaving them in place causes no problems. If you prefer a clean table, you can remove them:

python manage.py migrate core --prune
python manage.py migrate health --prune

--prune removes rows that no longer correspond to a migration file on disk. It operates on one app at a time, so both apps must be run separately.

Note: Running --prune blocks rollback to v0.9. Without the old migration records in django_migrations, a v0.9 image will treat migrations 0002 and later as unapplied and attempt to run them against an already-migrated schema, causing startup failures. Only prune if you are confident you will not need to roll back. If you do need to roll back after pruning, start the v0.9 container with SKIP_MIGRATIONS=true, exec in, run python manage.py migrate --fake, then restart without the flag.

Plugin authors¶

If you maintain a plugin with migrations that depend on a specific migration in core or health, update those dependencies to point to 0001_initial:

dependencies = [
    ('core', '0001_initial'),  # was ('core', '0014_aircraftfeature') or similar
]

Any plugin whose migration references a now-deleted migration name (e.g. core.0014_aircraftfeature) will raise NodeNotFoundError when Django builds the migration graph. The example plugin shipped with this project has been updated accordingly.