Contact usRequest a demo

Release policy and versioning

An understanding of the Unblu versioning scheme and its implications for the support life cycle is important for planning your own update schedule.

Versioning scheme

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:

Timeline of 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 8

18 April 2024

n/a

Unblu 7

30 August 2021

17 April 2026

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 or Unblu Spark 8. 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 or Unblu Spark 8. iOS mobile SDK v4 isn’t compatible with Unblu server v6.
Table 5. Web API life cycle events
Version Availability End of support period

4

18 April 2024

n/a

3

29 November 2019

deprecated

2

14 March 2019

deprecated

1

27 July 2017

30 August 2021

The release of Unblu Spark 8 triggered the support countdown for Unblu Collaboration Server v7.

Versions 2 and 3 of the web API were deprecated with the release of Unblu Spark 8 and version 4 of the web API. They won’t be available in Unblu Spark 9.

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.