Upgrade and Release Process

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

Unique's current release cycle is bi-weekly. Depending on the customer's 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 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:

* 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 a 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:

1. Unique discovers an added value for the client and progresses the change to BETA.
2. 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

1. PRD is complete and PRD review took place
2. Teamfood complete
3. All QA tests are passed
4. No CRITICAL bugs remain
5. 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 is 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

1. 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)
2. Changes that require configuration or flags do not require this criteria.
3. No CRITICAL or HIGH defects remain
4. Metrics implemented:
   1. They can be triggered and the data can be captured
   2. Metrics gathering process is in place
5. Any final revisions to documentation have been folded in and published
6. Developer documentation is complete

Release Content

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

One Unique release consists of:

Release Naming

Unique release names follow mostly CalVer:

<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

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

2024.28-abcdef

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.

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:

1. Calendar Week (CW): There are 52 weeks in a year.
2. 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.

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.