Tarantool release policy
The Tarantool release policy is changing to become more clear and intuitive. The new policy uses a SemVer-like versioning format, and introduces a new version lifecycle with more long-time support series. This document explains the new release policy, versioning rules, and release series lifecycle.
The new release policy replaces the legacy policy for:
2.x.yseries since the
2.10.0release. Development for this new release starts with version
- The future
Here are the most significant changes from the legacy release policy:
- The third number in the version label doesn’t distinguish between
pre-release (alpha and beta) and release versions.
Instead, it is used for patch (bugfix-only) releases.
Pre-release versions have suffixes, like
- In the legacy release policy,
1.10was a long-term support (LTS) series, while
2.x.yhad stable releases, but wasn’t an LTS series. Now both series are long-term supported.
The topics below describe the new versioning policy in more detail.
The new Tarantool release policy is based on having several release series, each with its own lifecycle, pre-release and release versions.
- Release series
- Release series is a sequence of development and production-ready versions with linear evolution toward a defined roadmap. A series has a distinct lifecycle and certain compatibility guarantees within itself and with other series. The intended support time for each series is at least two years since the first release.
- Release version
Release version is a Tarantool distribution which is thoroughly tested and ready for production usage. It is bound to a certain commit. Release version label consists of three numbers:
These numbers correspond to the three types of release versions:
- Major release
- Minor release
Minor release introduces a few new features, but guarantees backward compatibility. There can be a few bugs fixed as well. Such release changes the second version number:
MAJOR.MINOR.0 3.1.0 3.2.0
- Patch release
Patch release fixes bugs from an earlier release, but doesn’t introduce new features. Such release changes the third version number:
MAJOR.MINOR.PATCH 3.0.1 3.0.2
Release versions conform to a set of requirements:
- The release has gone through pre-release testing and adoption in the internal projects until there were no doubts regarding its stability.
- There are no known bugs in the typical usage scenarios.
- There are no degradations from the previous release or release series, in case of a major release.
Backwards compatibility is guaranteed between all versions in the same release series. It is also appreciated, but not guaranteed between different release series (major number changes). See compatibility guarantees page for details.
- Pre-release version
Pre-release versions are the ones published for testing and evaluation, and not intended for production use. Such versions use the same pattern with an additional suffix:
There are a few types of pre-release versions:
- Development build
Development builds reflect the state of current development process. They’re used entirely for development and testing, and not intended for any external use.
Development builds have suffixes made with
$(git describe --always --long)-dev:
MAJOR.MINOR.PATCH-describe-dev 2.10.2-149-g1575f3c07-dev 3.0.0-alpha1-14-gxxxxxxxxx-dev 3.0.0-entrypoint-17-gxxxxxxxxx-dev 3.1.2-5-gxxxxxxxxx-dev
- Alpha version
Alpha version has some of the features planned in the release series. It can be incomplete or unstable, and can break the backwards compatibility with the previous release series.
Alpha versions are published for early adopters and developers of dependent components, such as connectors and modules.
MAJOR.MINOR.PATCH-alphaN 3.0.0-alpha1 3.0.0-alpha2
- Beta version
Beta version has all the features which are planned for the release series. It is a good choice to start developing a new application.
Readiness of a feature can be checked in a beta version to decide whether to remove the feature, finish it later, or replace it with something else. A beta version can still have a known bug in the new functionality, or a known degradation since the previous release series that affects a common use case.
MAJOR.MINOR.PATCH-betaN 3.0.0-beta1 3.0.0-beta2
Note that the development of
2.10.0, the first release under the new policy, starts with version
- Release candidate
Release candidate is used to fix bugs, mature the functionality, and collect feedback before an upcoming release. Release candidate has the same feature set as the preceding beta version and doesn’t have known bugs in typical usage scenarios or degradations from the previous release series.
Release candidate is a good choice to set up a staging server.
MAJOR.MINOR.PATCH-rcN 3.0.0-rc1 3.0.0-rc2 3.0.1-rc1