Stability and releases

Beignet is alpha software on the 0.0.x line. Public APIs can change between releases, including patch releases. Before upgrading, read the package changelogs and upgrade guide, then test the affected workflows in your app.

Versioning

All @beignet/* packages and create-beignet share a version number. Install matching versions so your app uses a supported combination of packages.

While the packages are pre-1.0:

• Every release uses a patch bump on the 0.0.x line, including breaking changes. A patch increment does not promise compatibility.
• Package changelogs and the upgrade guide describe breaking changes and the actions needed to upgrade.

How releases ship

Packages are published to npm with coordinated versions and changelogs. Each published package includes its CHANGELOG.md, so you can read the release notes alongside the version you installed.

What every release passes

Release validation checks the parts you depend on when building and deploying an app:

• Package tests, TypeScript inference, production builds, and documentation examples.
• Generated apps with SQLite, Postgres, and MySQL, including sign-up, authenticated Todo operations, idempotency replay, OpenAPI, and devtools over HTTP.
• Transaction, outbox, and idempotency behavior across the supported database adapters, plus Redis event delivery and distributed locks.
• Package contents, matching versions, and documented public API changes.

These checks do not replace tests for your app's authorization rules, workflows, and deployment configuration. See Testing and Deployment for checks to run in your own project.

The road to 1.0

A 1.0 release requires stable public APIs, production experience with events, jobs, schedules, outbox, idempotency, and notifications, and a written compatibility policy with migration notes for breaking changes.

There is no announced date for 1.0. Until then, expect the compatibility limits of the 0.0.x line.

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. Check the migration notes before updating imports, types, or configuration, and run your app's typecheck and tests after upgrading.

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.