Skip to content

0.17.0

Choose a tag to compare

@igorbenav igorbenav released this 08 May 02:09
84a70f2

Release v0.17.0 - Final Polish Before the Rebuild

Release Notes by FastAPI-boilerplate team

This is the final release of FastAPI-boilerplate in its current shape. After this, we're tearing the layout apart and rebuilding it as a real plugin system, then shipping 1.0 at the end. If you want to stay on the old shape, pin to v0.17.0 — once the restructure starts, main will be unstable for a while.

The changes in this release are mostly polishing. A lot of credit to @rragundez for cleaning up the settings layer — CORS got proper middleware, the .env file was being loaded twice through different code paths and now it isn't, hosts validation is in place, and the SQLite/MySQL settings classes that nobody actually used are gone (we're committing to Postgres as the default going forward). @sri-dhurkesh integrated structlog, so logging is actually structured now instead of f-string soup. @carlosplanchon updated dependencies for Python 3.14 and moved the installation scripts to a proper folder. We bumped FastCRUD to 0.19.2.

Nothing here should break apps you've built on the boilerplate. The breakage comes next.

Why we're restructuring

If you've cloned this template and tried to remove a feature you didn't want — say, posts — you've probably noticed it lives in five or six folders (models/, schemas/, crud/, api/v1/, plus the aggregator __init__.py). Easy to miss a file. People end up with dead code they didn't want, or they delete by hand and break imports somewhere downstream. That's the actual problem we're fixing.

The other thing that bothers us: cache is hard-coded to Redis, queue is hard-coded to ARQ, auth is hard-coded to JWT. If you want Memcached, Taskiq, or session-cookie auth, you have to fork the boilerplate and edit core. That's where most real users diverge from the template, and it's exactly the divergence that makes it stop receiving upstream updates cleanly. We want to fix that too.

users, tiers, auth, and health stay core in 1.0 — making everything a plugin would be a different project (and would mean 1.0 never ships). Save it for 2.0 if it ever matters.

Versioning during the restructure

Sticking with ZeroVer until 1.0. Each milestone is a tagged release you can pin to.

Each tag is independently shippable — if life intervenes, every milestone is a usable end state, not a half-finished refactor. Migration guides will land with each release that has breaking changes.

While we're in 0.x, once 0.x+1.y is released, support for 0.x.y is dropped. Eventually we'll get to SemVer at 1.0.

If you want to talk to us

Join us on Discord, open an issue, or ping @igorbenav on the repo. The restructure is a real chance to influence the shape of the boilerplate going forward — if there's something you want from a plugin system (a specific capability slot, a manifest field, a CLI command), now's the moment to say so. Easier to land it in 0.18 than to retrofit it post-1.0.


What's Changed

New Contributors

Full Changelog: v0.16.0...v0.17.0