What's coming
🔧 In progress
tracing evolution
in progresse to local
Fix Makemigrations
test in prod and for moment , one bug => ; [default: …]` was still dropped on enum columns:** the 2.1.15 fix made `render_column_def` emit `.default()`, but only on the non-enum branch — the `ColumnType::Enum` branch was rendered with `{null}{uniq}` and never appended `{default}`. A `choice [enum(X)]` column with a `[default: "Y"]` therefore lost its default, and a `required` (NOT NULL) enum column added to a populated table failed at migration time with `column "…" contains null values`. Fixed: the enum branch of `render_column_def` now appends `{default}` like every other column, so an `ADD COLUMN NOT NULL DEFAULT ''` lets Postgres backfill existing rows instead of erroring. The emission is engine-independent (Postgres/MySQL/SQLite); the Postgres-only `CREATE TYPE` gating is unchanged.
Bug(s) and fix(es)
Detection and correction of bugs. If you encountered unexpected behaviour, feel free to open an issue or contribute a PR!
Known issues Changelog📋 Planned
Boot validation
Refuse startup in production if the configuration is inconsistent or incomplete.
DX
cargo-watch not included. Template hot-reload in dev is only active when DEBUG=true.
🔭 Future
Forms
Rework of the system towards a widget-based approach.
Refactoring — widget field system
The file() option is a pragmatic solution. The long-term direction is a refactoring of the field system to widgets (Django-style): each model field will be able to declare its render type independently of its SQL type.
Fieldsets + readonly fields
Basic but blocking for many admin use cases
Cumulative filters + FK filters
Admin DX, many potential requests
CSV/JSON export
Quick win, frequently requested
Advanced save buttons
Django parity, not complex
Date-based navigation (date_hierarchy)
Nice to have
Admin inline
More complex, wait for widget refactoring?