Stability and releases

Beignet is alpha software on the 0.0.x line. Concretely, that means the public API can still change between releases while the framework settles. It does not mean the project is unmaintained or untested: every release ships through changesets with a documented changelog, and every commit passes the same CI gates, including a conformance check that scaffolds, builds, and boots real generated apps against real databases.

Versioning

All @beignet/* packages and create-beignet version together as a fixed changesets group, so a given version number always refers to one coherent release across the whole framework. Installing any Beignet version gives you packages that were tested together.

While the packages are pre-1.0:

• Every change is a patch bump on the 0.0.x line, including breaking changes. Do not read semver meaning into 0.0.x increments.
• Breaking changes are documented through changesets, package changelogs, and the upgrade guide.
• Releases ship as changes land. The project has released multiple times per month since work started, often several times in a single week.

What every release passes

Every Beignet version published to npm passes the same reproducible release-candidate gate:

• The full test matrix with coverage, including provider tests that run against real Postgres and MySQL servers, plus lint, typecheck, and build for every package.
• Architecture linting that enforces the dependency direction the framework teaches: domain code cannot import infra, use cases cannot import providers, routes cannot import concrete adapters.
• Pack and release alignment checks that verify published package contents and keep the fixed version group consistent.
• Committed API reports for every published TypeScript entry point. CI fails when an export, overload, generic, or referenced public declaration changes without an intentionally reviewed report update.
• A generated-app conformance check that scaffolds real apps with the CLI, installs dependencies, typechecks, production-builds, passes lint and strict doctor checks, then boots the built app and exercises sign-up, authenticated todo create/list/update/delete, idempotency-key replay, OpenAPI, and devtools over HTTP — against SQLite, Postgres, and MySQL.
• A cross-database conformance suite that proves the unit-of-work, outbox, and idempotency semantics are identical across the SQLite, Postgres, and MySQL backends.
• Live Redis integration tests for the distributed event bus and execution locks, plus a full-history secret scan.

The road to 1.0

1.0 is gated on outcomes, not dates:

• The public API grammar settles — the defineX and createX surfaces stop changing shape between releases.
• The workflow tier (events, jobs, schedules, outbox, idempotency, notifications) is validated in production use.
• A written compatibility promise ships: semver, with documented migration notes for any breaking change.

There is no announced timeline. The 0.0.x line continues until those gates are met.

Compatibility policy

Public API means the exports reachable through a package's declared package.json#exports paths. Internal source paths, generated build output, and undocumented files are not public API. App code produced by generators is owned by the app after generation; later generator improvements do not rewrite it automatically.

On the current 0.0.x line, releases may remove or reshape public APIs. Those changes must include migration notes and keep docs, package READMEs, generators, skills, and validation apps aligned in the same change. Public TypeScript API changes also update the committed API report and include a changeset for each affected package.

Starting with 1.0:

• Patch releases will contain backwards-compatible fixes and documentation.
• Minor releases may add APIs and deprecate existing ones without removing them.
• Major releases may remove deprecated APIs or make other breaking changes and will include an upgrade guide.
• All Beignet packages will continue to version together so the supported combination remains unambiguous.

Raw provider clients exposed as escape hatches retain their vendor's own compatibility behavior. Beignet guarantees the typed existence of a documented escape hatch, not that a vendor SDK will avoid its own breaking changes.

Following along

• The @beignet npm org lists every published package and version.
• Each package ships its CHANGELOG.md in the published npm package, with breaking changes called out per release.

The repository is not open source yet. The packages themselves are published publicly on npm.