Zum Hauptinhalt springen

OpenTalk Release Policy

Schedule​

OpenTalk releases are created after each development iteration. Each iteration takes 3 weeks, so a release can be expected roughly every 3 weeks as well.

Typically a new release candidate with the latest changes is created which will then undergo testing for one development iteration. Afterwards this release candidate will be declared a final release if no release-critical issues have been found.

If release-critical bugs are discovered in the release candidate and cannot be fixed with additional release candidates in time for the final release, a release may be skipped, and the corresponding version number is omitted.

Release Procedure​

Each OpenTalk product release consists of multiple components which have different version numbers. New minor or major versions of these components may be released in between, but not end up in an OpenTalk product release. At the same time, one release of a component may be used in multiple consecutive OpenTalk product releases if no changes have been implemented there. Because of this, only the final product releases documented on the releases page have undergone extensive testing, and although it might be the case, all other combinations of components are not guaranteed to work.

Because of that procedure, final releases of components may become visible in the repositories as tags or containers even before we publish that OpenTalk product release. If you want to be on the safe side, only use the sets of components documented on the releases page.

Version Numbers​

Each release that follows the regular release cycle follows the numbering scheme <X>.<Y>.<Z>.

  • <X> stands for the year in which the release is created, e.g. 24 when the release is created in 2024.
  • <Y> is the sequential number of the release within the year, e.g. 3 for the third release in 2024. Because one year has roughly 52 weeks, roundabout 17 releases per year can be expected.
  • <Z> is the patch number. This starts with 0 after each three-week development iteration, and whenever a patch release is published, the number is increased by 1.

Patch Releases​

If we discover bugs or security issues in the software after a final release has been published, then a patch release may be published. Functionality typically does not change for these releases, and it is usually safe to update a <X>.<Y>.<Z> version to <X>.<Y>.<Z+1>. We aim to keep the changes as specific and small as possible in order to avoid introducing new bugs.