Release policy and versioning

Versioning scheme

As of Unblu 5, Unblu versions comply with the Semantic Versioning specification. In this scheme, a version’s impact is usually measured with regard to the public API, often referred to as breaking changes.

The version numbers convey information about what has changed from one version to the next. Versions use a sequence of three digits--<major>.<minor>.<patch>(-<qualifier>)--to describe the impact of an update of the software. The meaning of the <major>.<minor>.<patch> version scheme is defined as follows:

A <major> digit increment is used when incompatible API changes are introduced,
A <minor> digit increment is used when functionality is added in a backwards-compatible manner.
A <patch> digit increment is used for backwards-compatible bug fixes.

Release versions are sparse, for example the next public version after 5.1.6 might be 5.1.9. This only applies to patches. Major or minor versions are incremented successively.

When the version is updated with an increment of the <minor> digit, this is called a new minor version. Once a new minor version is publicly available, there will be no <patch> updates for earlier minor versions. For example, if the last minor version was 5.1.5, there will be no release version 5.1.6 once 5.2.0 has been released.

The table below lists which types of change are permissible when the major, minor, or patch version of an Unblu software component is incremented.

Table 1. Permissible changes to Unblu software components by version increment type
	Major	Minor	Patch
Web API
Add a new method to an existing web API version	Yes	Yes	No
Add an optional input parameter to an existing web API version	Yes	Yes	No
Add a data type to an existing web API version	Yes	Yes	No
Add an optional field to an existing data type in an existing web API version	Yes	Yes	No
Add a new web API version	Yes	Yes	No
Remove an old web API version	Yes	No	No
JavaScript APIs (Embedded JS API, Floating JS API)
Deprecate an existing API	Yes	No	No
Remove an existing API	Yes	No	No
Change an existing API	Yes	No	No
Add a new API class or method	Yes	Yes	No
Configuration schema
Remove a configuration property	Yes	No	No
Change how a configuration property works	Yes	No	No
Add a configuration property	Yes	Yes	No
Text schema
Remove a text property	Yes	No	No
Change how a text property works	Yes	No	No
Add a text property	Yes	Yes	No
Database
Database changes	Yes (with automated migration)	Yes (with automated migration)	No
Visitor UIs
Add, remove, or change UI features	Yes	No	No
Add a feature that’s visible by default, with a property to disable or hide the feature	Yes	Yes	No
Add a feature that isn’t visible by default	Yes	Yes	No
Agent UIs
Add, remove, or change UI features	Yes	No	No
Add a feature	Yes	Yes	No
Adminstrative UIs (Account Configuration interface, Global Server Configuration interface)
Add, remove, or change UI features	Yes	No	No
Add a feature	Yes	Yes	No

Feature statuses

Features and their related configuration and text properties, web API endpoints, webhooks, and JavaScript methods, enums, and interfaces can have one of three statuses:

Preview
Stable
Deprecated

Unless stated otherwise, features and their configuration and text properties are stable. Stable configuration and text properties aren’t labeled.

Configuration and text properties with preview or deprecated status are labeled as such in the configuration and text property references, respectively.

Preview

Preview features are new features for you to try out. They may change or be removed in a future version without any notice. Substantial changes to preview features, such as renaming, modifying, or removing configuration properties, may occur in minor version updates of the product. You shouldn’t rely on them in production environments.

The status of a preview feature can change to either stable or deprecated. A preview feature may become a separately licensed feature when its status changes to stable.

Stable

Stable features adhere to the <major>.<minor>.<patch> version scheme. Changes to stable features in minor versions are backward compatible. If new configuration properties are introduced that replace old configuration properties, the old configuration properties will not adversely affect Unblu. Whether they affect Unblu at all varies from case to case.

The status of a stable feature can only change to deprecated.

Deprecated

Deprecated features are scheduled for removal from Unblu in the next major version. Configuration and text properties marked as Deprecated typically no longer affect Unblu.

Once a feature is deprecated, its status can’t change. The feature is simply removed from the next major version of Unblu.

Release life cycle

In addition to public releases, various internal releases exist during the development phase of a release stream.

Development versions: Versions published before a feature freeze. Development versions are released in the early development phase. They’re versioned according to the following pattern:

<major>.<minor>.<patch>-alpha.<increment>, for example 6.0.0-alpha.0, 6.0.0-alpha.1
Stabilization versions: After feature freeze, Unblu may release stabilization versions prior to the first public version of a stream.

<major>.<minor>.<patch>-beta.<number>, for example 6.0.0-beta.0, 6.0.0-beta.1
Hotfix versions: If a customer needs a hotfix, the version uses the pattern

<major>.<minor>.<patch>-hotfix.<number>, for example 5.1.3-hotfix.0, 5.1.3-hotfix.1

Alpha and beta versions are only prepared for major releases, there is no 5.2.0-beta.0 version.

The following diagram illustrates the Unblu release cycle:

Figure 1. Timeline of the Unblu release cycle

Standard support life cycle

Unblu supports major versions of the product for 24 months after the first official release date of the superseding major version of the product. This holds true regardless of how many subsequent major releases were made after the respective release.

As outlined above, the versioning scheme introduces no breaking changes in minor versions or patch versions. Customers on the previous major version will therefore be asked to upgrade to the latest minor or patch release to address potential problems with the software.

An upgrade of a minor release or a patch release will never require a migration effort on your part.

Example

To illustrate the support life cycle, suppose a new major version, Unblu 10.0.0, is released on 1 May 2022. At that time, the major version being shipped is 9.8.13.

The release of Unblu 10.0.0 triggers the support period countdown for the preceding version. The standard support period for version 9.x.x will end on 1 May 2024.

Customers on version 9.x.x of the platform will be asked to continue to upgrade to the latest minor/patch release of the Unblu 9 release train to address any problems.

If Unblu 11.0.0 were released before 1 May 2024, this would trigger the standard support countdown for version 10.x.x. The support countdown for version 9.x.x, however, would not be affected. It would continue until 1 May 2024.

Unblu 5.0 was a limited feature release. As a result, Unblu 5.1 replaced Unblu 4.3 and triggered the support life cycle countdown for version 4.x.

Recent and upcoming life cycle events

Table 2. Collaboration Server life cycle events
Version	Availability	End of support period
Unblu 7	30 August 2021	n/a
Unblu 6	29 November 2019	29 August 2023
Unblu 5	14 March 2019	22 November 2021
Unblu 4.3	27 July 2017	7 March 2021

Table 3. Android mobile SDK life cycle events
Version	Availability	End of support period
Android mobile SDK v4	4 October 2021	n/a
Android mobile SDK v3	07 May 2021	29 August 2023
Android mobile SDK v2	29 March 2019	22 November 2021

Android mobile SDK v3 isn’t compatible with Unblu server v5. Android mobile SDK v4 isn’t compatible with Unblu server v6.

Table 4. iOS mobile SDK life cycle events
Version	Availability	End of support period
iOS mobile SDK v4	14 October 2021	n/a
iOS mobile SDK v3	07 May 2021	29 August 2023
iOS mobile SDK v2	29 March 2019	22 November 2021

iOS mobile SDK v3 isn’t compatible with Unblu server v5. iOS mobile SDK v4 isn’t compatible with Unblu server v6.

Table 5. Web API life cycle events
Version	Availability	End of support period
3	29 November 2019	n/a
2	14 March 2019	n/a
1	27 July 2017	30 August 2021

The release of Unblu 7 triggered the support countdown for the following products:

Unblu Collaboration Server v6
Unblu mobile SDK v3

Collaboration Server and mobile SDK compatibility

Releases of the Collaboration Server and the mobile SDKs don’t take place at the same time. To determine whether a particular version of the Collaboration Server is compatible with a particular version of one of the SDKs, follow the guidelines below:

The principle component is the Collaboration Server. Releases of the mobile SDK are compatible with the latest version of the Collaboration Server available when the mobile SDK is released.
A mobile SDK version remains compatible with minor versions of the Collaboration Server released after the mobile SDK was released.
Once an SDK reaches the end of its support period, there is no guarantee that it will remain compatible with new minor versions of the Collaboration Server.

Consider the following example: Android mobile SDK 3.4.2 was released on 14 June 2021. At the time, the latest version of the Collaboration Server was 6.35.0, which was released on 11 June 2021. As a result, Android SDK 3.4.2 is compatible with 6.35.0 and subsequent minor and major versions of Unblu. This is the case until 29 August 2023, when the support period for version 3 of the mobile SDKs ends.

There are no guarantees that Android mobile SDK 3.4.2 is compatible with version 6.34.4 of the Collaboration Server, which was released on 21 May 2021, or earlier versions of the Collaboration Server.