Skip to main content
Version: 18

Release Policy

Versioning strategy​

Versions have the following format: x.y-yymmddhhmm, where x is the major version, y is the minor version, and yymmddhhmm is the date and time of the release.

Release frequency​

Releases are built daily for each active minor version. Due to our Backward Compatibility Policy, deployments can also be done every day, which allows fast delivery cycles and quick bug resolution.

Major versions​

Major versions typically contain significant changes to the platform, such as new features, breaking changes, or major improvements. For each major version, a detailed executive summary is provided. Optionally, a migration guide is provided to help transition to the new version.

Major versions typically contain:

  • New product features
  • Product improvements
  • Bug fixes
  • Database migrations

Minor versions​

Minor versions typically contain:

  • Bug fixes
  • Database migrations

A minor version is typically needed when migration bugs were discovered in a major version. Minor versions are avoided, because contrary to a major version, no manual testing cycle is performed, but the version might still contain database migrations, which introduces regression risks.

Patch versions​

Path versions typically contain:

Path versions cannot contain:

  • Breaking changes (e.g., modifications or removal of custom code that is used in production)
  • Database migrations

Since patch versions do not contain database migrations and must be fully backward compatible, they can be deployed at any time without supervision. However, bug-fixes might introduce new bugs, so it is recommended to only deploy a certain patch version to production after it has been tested in a staging environment.