Each minor release makes one claim on wagoe.org true that was not quite true yet. 1.0 made the stability promise, 1.1 authorization. What comes next is below, in order, and what every release does besides is at the bottom.
There are no dates. With one maintainer they would be fiction; the order is the promise.
Released. Routes check permissions, roles and scopes under
:wagoe/authorization, in one of three modes: :off, :report, which logs
every request it would refuse, and :enforce, which new apps start in. The
admin manages groups and roles, explains why a user may or may not do
something, and shows who gains and loses rights before a change saves. Start
with the Authorization guide; an existing app
moves over with Upgrading
authorization.
Add wagoe-user for auth this week and nothing else — that’s a valid way in.
Why it is not quite true. In the source it nearly is. In your dependency tree
it is not: wagoe-user brings wagoe-platform, and with it the HTTP server,
the router, the CLI and around fifty other dependencies. Jobs, events, storage,
search, push, webhooks and tenancy bring the same, although their code uses only
the database part.
What 1.2 does. The database part of wagoe-platform becomes its own library,
wagoe-platform-sql, with no HTTP stack, and the data libraries depend on that
instead. Namespaces keep their names and wagoe-platform still brings
wagoe-platform-sql along, so nothing breaks. Every library declares exactly
the Wagoe libraries its source requires. SQL stays out of core/ and out of
port signatures, so a module of your own can keep its data in any store. Each
library page says which ring it is in: standalone, needs only wagoe-core, or
needs the platform.
How you see it is done. bb check:deps fails a library that declares a Wagoe
library its source does not require, bb check:fcis fails SQL in core/ or in
a port, and the homepage sentence says what is then true, ring by ring.
Declare an entity; the list, search, filters, sorting and bulk actions come with it.
Why it is not quite true. The screens are there. But the admin is the library
most likely to become a silo: workflow imports it, the screens wear Wagoe’s
look instead of your app’s, and the entity configuration is a format of its own
that no single page explains.
What 1.3 does. Modules contribute to the admin through a port instead of
importing it, so no domain library depends on the admin. Everything the admin UI
can do, its ports can do: a different admin, or an API with none, is built on
the same contract. The admin wears your app’s design tokens. Entity
configuration gets a reference generated from its own schema, and is derived
from your module’s Malli schema, so it describes your domain rather than the
admin. And the last mile on lists, record pages, the dashboard, phones and the
keyboard. Still no build step and no node_modules.
How you see it is done. bb check:deps fails any domain library that depends
on the admin, and the screenshots on the homepage are of 1.3.
Eight libraries are published as incubating and sit outside the guarantee, because we already know their API is not finished.
Why it is not quite true. Marking what is unfinished is honest only while the
list gets shorter. Since 1.0 it has not: payments, config, ai, geo,
external, reports, audience and workflow are all still incubating.
What 1.4 does. Each of them gets a verdict: stable, deliberately incubating
with the reason and what would promote it, or folded into or split out of
another library. None stays incubating by default. A library that is ready
earlier graduates earlier; 1.4 is the deadline for the verdict, not the only
chance. audience and workflow can only graduate once their ports lose their
SQL (1.2), and workflow once it no longer depends on the admin (1.3).
How you see it is done. The stability page gives every
incubating library a verdict and a reason, and a new gate, bb check:tier,
fails the build when one has none.
Wagoe makes those tools produce code that’s architecturally correct, immediately mergeable, and consistent with everything already in the codebase.
Why it is not quite true. Today that rests on a terminal recording, not on a number.
What 1.5 does. A nightly run, started well before 1.5, gives bb scaffold ai
fixed tasks against real AI providers and records how many come out compiling,
tested and passing the architecture gates without an edit. 1.5 grows it to
about twenty-five tasks, in English and Dutch, across every kind of module the
scaffolder knows and several providers, and measures an agent working through
wagoe-mcp end to end. The tasks that fail most become fixes to the templates,
the agent guidance or the ports, and the number shows whether each fix helped.
How you see it is done. Every night’s result is public on wagoe.org, with the modules it generated, and the claim above carries the number and the tasks that still fail.
Every release closes every known security issue before it is tagged. Report a vulnerability privately through a GitHub security advisory.
Each release names three starter tasks that are smaller than the framework — an adapter, a translation, a deployment guide, a benchmark task — each with a short brief, and its release post names who contributed. A pull request gets a decision within two working days. Start with CONTRIBUTING.md.
2.0 removes what 1.x deprecates, once each deprecation has run its term of one minor release and 90 days. Nothing else is planned for it, and it has no date.
The detail of every release is in CHANGELOG.md. What 1.0 promises, and which libraries it does not cover yet, is on the stability page. What scales today is on Sizing & Scaling.
This roadmap is the only one. It is updated with every release post, and the post quotes this page, not the other way round. Work is tracked on GitHub.
A CI gate (bb check:roadmap) fails the build if this page plans something
Sizing & Scaling already marks as shipped, which
is how the three-way contradiction it replaced went unnoticed for months.
If something here matters to you, saying so is the most effective way to move it up the list.
Stability & Versioning — what 1.0.0 promises
Getting Started — try it
Sizing & Scaling — what scales today
Can you improve this documentation? These fine people already did:
thijscreemers & Thijs CreemersEdit on GitHub
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |