# Polyfactory Releases

This document outlines the release structure, versioning, and stability guarantees for the Polyfactory library.

## Version Numbering

This library 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.

## 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 organization 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.