Litestar Releases#

Version Numbering#

Litestar follows the Semantic Versioning standard, using the <major>.<minor>.<patch> schema:

Major

Backwards incompatible changes have been made

Minor

Functionality was added in a backwards compatible manner

Patch

Bugfixes were applied in a backwards compatible manner

Pre-release Versions#

Before a new major release, we will make alpha, beta, and release candidate (rc) releases, numbered as <major>.<minor>.<patch><release_type><number>. For example, 2.0.0alpha1, 2.0.0beta1, 2.0.0rc1.

  • alpha

    Early developer preview. Features may not be complete and breaking changes can occur.

  • beta

    More stable preview release. Feature complete, no major breaking changes expected.

  • rc

    Release candidate. Feature freeze, only bugfixes until final release. Suitable for testing migration to the upcoming major release.

Long-term Support Releases (LTS)#

Major releases are designated as LTS releases for the life of that major release series. These releases will receive bugfixes for a guaranteed period of time as defined in Supported Versions.

Release Cadence#

Litestar aims to release a new major version every 12-18 months, with minor releases every 4-6 weeks.

Note

This schedule is flexible and may change based on community feedback and development progress.

Deprecation Policy#

When a feature is going to be removed, a deprecation warning will be added in a minor release. The feature will continue to work for all releases in that major series, and will be removed in the next major release.

For example, if a deprecation warning is added in 1.1, the feature will work throughout all 1.x releases, and be removed in 2.0.

Supported Versions#

At any time, the Litestar team will actively support:

  • The current major release series

  • The previous major release series

  • Any other designated LTS releases (Special cases)

For example, if the current release is 2.0, we will actively support 2.x and 1.x. When 3.0 is released, we will drop support for 1.x.

Bugfixes will be applied to the current major release, and selectively backported to older supported versions based on severity and feasibility.

Release Process#

Each major release cycle consists of a few phases:

  1. Planning: Define roadmap, spec out major features. Work should begin on implementation.

  2. Development: Active development on planned features. Ends with an alpha release and branch of A.B.x branch from main.

  3. Bugfixes: Only bugfixes, no new features. Progressively release beta, release candidates. Feature freeze at RC. Become more selective with backports to avoid regressions.

Business / Enterprise Support#

While our typical release cadence and LTS strategy is designed to support most users, we understand that some organizations may require additional support. If you require this support we are happy to work with you on a custom support agreement. Please contact us via our official support channels:

Note

While we are committed to delivering the best possible experience for all users, including those in larger-scale or slower-moving environments, please note that this does not constitute a guarantee of SLAs or paid support.