Upgrade and Release Process

7 min read

Description of the Unique AI release process and potential instructions for rolling them out in the different Infrastructure.

Version Support and Maintenance Policy

Scope

Unique supports only the current (latest) and previous (n-1) versions at any time. Older versions are unsupported and must be upgraded.

Versioning

Unique follows CalVer convention, see #Release-Naming for details.

Maintenance Rules

Functional updates (features, non-security fixes as well as regular dependency updates) are provided only for the latest minor version.
Security updates are provided as follows:
- Critical / High (CVSS ≥ 7.0): Patched in the current and previous (n-1) minor versions of the latest major release.
- Medium / Low: Fixed only in upcoming releases.
When a new CalVer minor version is released, all older minor versions are automatically deprecated.
When a new CalVer minor version is released, the last minor version of the previous major receives only Critical/High security fixes—no new features or other updates.

End of Support

Versions older than n-1 (whether major or minor) receive no maintenance or patches of any kind. Affected deployments must upgrade to a supported version.

Regular releases

Uniques current release cycle is bi-weekly. Depending on the customers choice this frequency can be lowered upon request.

However, the SLA is only valid if the Client deploys at least once a month as bugfixes are only performed on the latest version of the software.

While the frequency for self-hosting tenant can be increased by the client themselves, Unique does not offer a higher frequency for Single-Tenants.

Release notes are always published before a release is being provided on Release Notes 2026.

Release Lifecycle

Releasing software in phases allows developers to manage risk and improve product quality by systematically testing and refining the software. It begins with internal testing to catch major bugs, then moves to external testing where real-world users provide feedback on functionality and usability. The release candidate phase follows, focusing on identifying remaining critical issues before the final version. This phased approach helps ensure that the software is stable, meets user needs, and reduces the likelihood of significant issues in the final release, thus enhancing customer satisfaction and reducing costly post-release fixes.

Phases and Objectives

Unique currently maintains the following phases:

Phase	Key aspects	Target group
`FAST PROTOTYPE`*
`EXPERIMENTAL`*	Trying out and innovating new changes Focus on basic functionality and core features Are not designed to but expected to fail	Selected individuals or groups specifically opting in for experimental testing
`BETA`*	External testing with real users or clients Collecting feedback on performance and usability Should no longer fail for most cases	Interested stakeholders Users/Clients/Tenants specifically opting in for beta testing
`GENERAL AVAILABILITY (GA)`	Final, stable, secure release to the public Continuously maintained and enhanced Long-term commitment to functionality	Product is considered complete and ready for all users/clients/tenants

* These phases are explicitly excluded from any SLA, only changes that have matured to GA are covered by any SLA. Support for these changes is on best-effort basis.

Experimental

EXPERIMENTAL* changes or features are tested with a very small user base, to validate their potential value. These features may:

Change significantly or be discontinued without notice
Have incomplete or outdated documentation
Include breaking changes in future iterations

EXPERIMENTAL features have two possible outcomes:

Unique discovers an added value for the client and progresses the change to BETA.
Unique identifies issues, problems or inefficiencies and basically terminates the experiment.

Unique believes in transparent innovation. By sharing experimental work, we enable clients to discover new possibilities, provide feedback, and collaborate on solutions that benefit everyone.

Documentation Disclaimer

This feature is EXPERIMENTAL and under active development. It may change significantly, be discontinued, or have breaking changes without notice. Documentation may be incomplete or outdated and is not recommended for production use. Use at your own risk. Please refer to our Upgrade and Release Process for more information.

Beta

BETA* features are actively being tested and refined with a broader user base. While functional and documented, these features may still undergo changes based on user feedback and testing results. Beta features are evaluated for promotion to full release based on performance, user adoption, and feedback.

Attributes of Beta

PRD is complete and PRD review took place
Teamfood complete
All QA tests are passed
No CRITICAL bugs remain
Documentation is published:
1. User documentation
2. Administrator Documentation

Documentation Disclaimer

This feature is currently in BETA. It may change before general availability, due to user and client feedback, but it targeted to be high quality and stable. Documentation may lag behind feature updates. Use in production environments at your own discretion. Please refer to our Upgrade and Release Process for more information.

General Availability (GA)

GA features are fully released to all clients, users, and tenants with complete documentation and ongoing support. These production-ready features are continuously maintained and enhanced by Unique's product teams. While deprecation is uncommon, it may occur with proper advance communication, migration guidance, and appropriate transition timelines.

Attributes of GA

For changes that are visible or available to clients/users without any flags or configuration – minimum 3 clients have used it for 2-4 weeks (rule of thumb: 1 month after beta deployment)
1. Changes that require configuration or flags do not require this criteria.
No CRITICAL or HIGH defects remain
Metrics implemented:
1. They can be triggered and the data can be captured
2. Metrics gathering process is in place
Any final revisions to documentation have been folded in and published
Developer documentation is complete

Release Content

As seen in the Secure Software Development Lifecycle (Secure SDLC), Unique provides a variety of artefacts per release, delivery or rollout cycle.

One Unique release consists of:

Artefact	Model	Further Use	Format	Consumable
Unique Product	all	Run Unique workloads with a container orchestrator	Multiple Docker Images	Either as files forked to own Git, tarballs or images from a private Azure Container registry
Connectors (On Premise and Cloud)	SELF-HOSTEd	Upgrade local installations of various connectors to connect to the Unique Product	Multiple Docker Images	Either as files forked to own Git, tarballs or images from a private Azure Container registry
Helm Charts	SELF-HOSTEd	In order to run Unique on Kubernetes, helm charts are the recommended way to render and apply Kubernetes manifests.	Multiple Helm	Either as files forked to own Git or tarballs from a private Azure Container registry
Terraform modules	SELF-HOSTEd	Terraform own Azure Landscape or just get inspired which components are needed	HCL for Azure	Either as files forked to own Git or published over Azure Container registry
SBOM Software Bill of Materials	all	For further analysis for customers, pinned to the current release	SPDX format incl. Grype Scan results	As files
Release notes	all	A change log for humans	Text	Public docs
Customization examples	SELF-HOSTEd	Customise each setup from example cases	YAML	Files forked to own Git, then overridden

Setting up & Maintaining Releases

Learn more about it in Rollout Guidelines

Release Naming

Unique release names follow mostly CalVer:

text

<YYYY>.<CW>(.I)
YYYY Year
CW Calendar Week Padded
I Numeric counter if fixes provided

<YYYY>.<CW>(-SHA)
YYYY Year
CW Calendar Week Padded
SHA Build version for continuous releases
–––––––––––––––––––––––––––––––––––––––––––––
EXAMPLE:
2023.01 // padded
2023.12
2023.34
2023.34.1 // patch 1

Note on the format

Selection of the latest format

To create a Docker tag that includes the components YYYY (year), CW (calendar week), and a 6-character Git short SHA, you can use a delimiter to separate these components clearly. Given the nature of Docker tags and to ensure readability and consistency, a suitable format would be:

YYYY.CW-GITSHA

Here's what each component represents:

YYYY: Year, represented by four digits (e.g., 2024).
CW: Calendar week, typically represented by two digits (e.g., 01 for the first week of the year).
GITSHA: Git short SHA, the first 6 characters of the Git commit hash.

Example

If today is July 11, 2024, and the Git short SHA is abcdef, the Docker tag could look like this:

2024.28-abcdef

Explanation of the format

Dot (.) between YYYY and CW: The dot separates the year and the calendar week, providing a clear distinction between these temporal components.
Dash (-) between CW and GITSHA: The dash separates the calendar week from the Git short SHA, helping to distinguish between the time-based portion and the Git-related portion of the tag.

Advantages of this format

Readability: Using dots and dashes makes the tag easy to read and understand, aligning with typical versioning practices.
Consistency: This format is consistent with common Docker tag conventions, ensuring compatibility with Docker registries and tools.
Clarity: Each component (YYYY, CW, GITSHA) is clearly delineated, making it straightforward to parse and comprehend the tag's meaning.

By following this format (YYYY.CW-GITSHA), you achieve a well-structured Docker tag that incorporates both temporal and source control information in a clear and standardized manner.

Collisions risk

The collision risk depends on the probability of two different commits having the same short SHA within the same calendar week. Let's break down the components:

Calendar Week (CW): There are 52 weeks in a year.
Git Short SHA: The Git SHA-1 hash is a 40-character hexadecimal string, and the probability of collisions is extremely low even for shorter versions of this hash.

Calculating Collision Probability

For 3-character SHA:

There are 163=4096163=4096 possible combinations.
The chance of collision increases with the number of commits, but for practical purposes, the risk remains relatively low for small to moderate repositories.

For 4-character SHA:

There are 164=65536164=65536 possible combinations.
This significantly reduces the risk of collisions compared to a 3-character SHA.

Recommendation

Using a 4-character SHA reduces the collision risk significantly compared to a 3-character SHA and is generally sufficient for most practical purposes.