Release Control: Semantic Versioning

The Jeak project will be released using a semantic versioning approach. This allows both plugin developers and administrators to instantaneously recognize breaking changes to the API.

The Version schema

Version numbers are composed from three integer numbers separated by dots. The first number will be the major version, the second the minor and the third will be the bugfix version.
With updates, the numbers will only increase resulting in higher numbers always corresponding to a more recent version of the framework and API.

Major Updates

Major updates will increase the major version and reset minor and bugfix version to 0. These updates are allowed and correspond to major breaking changes. Existing plugins are not to be considered compatible unless manually updated.
Major updates will be the least frequent update type observed.

Minor Updates

Minor updates will increase the minor version and reset bugfix version to 0. They are allowed to introduce deprecations in order to prepare plugin developers for the next major release but working compatibility must be maintained.
Minor updates may introduce new features, services and integrations. Thus, downgrading the minor version may introduce incompatibilities while upgrading must not.

Special exemptions: Minor updates may be partly breaking for severe issues. (For example critical security fixes.) This allows administrators to apply security fixes in LTS versions. Plugin-developer intervention must be kept to a minimum in these cases.

Bugfix Updates

Bugfix updates increase the bugfix version. They are expected to be the most frequent updates.
Administrators have to be able to apply these updates without additional thought, meaning that no incompatibilities are allowed to be introduced by bugfix updates.
For bugfix reasons, additions may be made on a code-level (new methods, overloaded method with additional parameters or similar) but must not cause semantic incompatibility!

❗️

Snaptshot-Notice

While releases may not be re-deployed re-using the same version number, snapshot releases may!
Do not use -SNAPSHOT releases in productive environments!

Long Term Support (LTS)

Some major releases may be designated "LTS" releases. That means, the release will be at least bugfix supported although a more recent major version may already be released. Such releases are not replaced by their succeeding major release.
An LTS versions support may only be discontinued when at least one other LTS version has been released for more than six months. Additionally, discontinuation of a LTS release may only happen after three months notice.

New features may or may not be added to LTS versions depending on whether or not the LTS version would support addition of the feature. Feature updates to LTS versions may be delayed with regard to more recent major releases. This allows both new features to be tested in their native release and framework developers to focus on one release version at a time.

📘

LTS notice

With project and community size, the definition of the LTS support is subject to change.
For example, the LTS timeframe may be increased.

👍

Partners notice

Project partners may receive extended support for discontinued LTS versions (as well as migration support) depending on the partner agreement achieved.
However, we do not have the capacity to support more than 2 LTS versions at a time for anyone. Therefore, when an LTS version has been discontinued and already has two successor LTS versions, support cannot be provided.