Release Versioning Format

The Jade version number structure is as follows.

First set of digits : Major Feature Release number that represents the year of the general release.
Second set of digits : Minor Feature Release number. Not currently used.
Third set of digits : Release number (01 denotes the Major Release; 02 and above denote releases consisting of consolidated updates at a minimum, and potentially functional improvements or minor new features built upon the Major Release)
Fourth set of digits : Hotfix number (targeted fix to address a specific issue)

Example: 25.0.01.005

Note: Starting with the Jade 2025 Major Release, we are aligning our release names with their actual version numbers — ending the “off-by-one” confusion that can arise, particularly when referring to Service Packs (for example: Jade 2022.0.05 is referred to as SP4).

We are introducing a new naming convention for each release of a particular Major Feature Release: R1, R2, R3, and so on, representing “Release 1”, “Release 2”, etc. The R1 release corresponds to the initial Major Release, and R2 and above correspond to what were previously called Service Packs.

Here’s how the new naming convention looks:

Release # Release Name

2025.0.01 = Jade 2025 R1

2025.0.02 = Jade 2025 R2

2025.0.03 = Jade 2025 R3

You will start to see this change reflected across our documentation and the Development Centre website when we release Jade 2025 R2 and beyond.

Components of the version number are incremented as follows.

When substantial new features are added and released, the Major Feature Release number is changed to reflect the year of release.
Periodically, as needed, all fixes (including hotfixes) introduced since the most recent Major Feature Release or consolidated release (R2 or later) are consolidated into a new release, which results in an incremented Release number (the third set of digits). In some cases, a non-Major release may also include carefully risk-assessed new features, as outlined in the 'New Features' section below.
When a hotfix is produced, the files involved will have their Patch (Build) number incremented.

Support Lifecycle for our Releases

We’re committed to providing stable, secure, and predictable support for your applications. This section outlines how our releases are structured and what the support lifecycle looks like.

Every Feature Release is supported for five years from its general release date. Within that period, patch frequency and support coverage follows this pattern:

In the first 18 months of a Feature Release’s life, at least one consolidated updates release will be produced.
For the remainder of the first four years of a Feature Release’s life, at least one consolidated update release will be produced. At the end of this period, the latest consolidated release will be the final consolidated release for this Feature Release.
For the final year (Year 5) of a Feature Release’s life, only the final consolidated release will be supported, and fixes will be produced for Priority A issues only. Customers wanting support in the final year will need to upgrade to the final consolidated release.
Upgrading across more than one Feature Release is not supported. For example, to upgrade from Jade 2020 to Jade 2025, it will be necessary to upgrade from Jade 2020 to Jade 2022 first, and then to Jade 2025.

Note: The five-year time frame applies to the entire Feature Release, starting from its general release date. It does not apply from the release date of each subsequent consolidated release within the Feature Release (see "Determining Where a Fault Is Addressed," below).

When a customer encounters an issue with the product:

They communicate this to us, and it is registered as a Contact.
The customer assigns the Contact’s initial priority and type (Contact or Fault).
If the customer believes they have encountered a fault and will require a hotfix for the issue (assuming that it is accepted by us as a fault), then we highly recommend that this be stated in the initial Contact. Unless it is otherwise obvious from the Contact, a statement of the impact/urgency of the issue is also useful information.
We will analyse the Contact with help from the Jade Plant when necessary.
If we determine that the issue is a fault with Jade, the Contact is converted to a fault (known as a Product Anomaly Report – PAR).
We can at any time change the priority.
Contacts not deemed to be a fault are either closed or we may suggest that you open a development idea via JEDI.

Component Support Policy (ESP, SSO, etc.)

For non-core components - e.g., Event Stream Producer (ESP), Single Sign On (SSO), we provide support for:

The current release and
One previous version (n-1)

Support includes:

Patching known bugs
Ensuring compatibility with the current platform
Applying critical security updates

Components outside this window are no longer supported, and customers are encouraged to upgrade.

Which Versions are Currently Supported?

Major Release: 2022

22.0.01: October 2022 --> End November 2027

22.0.02: May 2023 --> End November 2027

22.0.03: November 2023 --> End November 2027

22.0.04: November 2024 --> End November 2027

Major Release: 2022

25.0.01: October 2025 --> End October 2030

Non-Core Features:

Event Streaming Producer (ESP)

22.0.04.005 March 2025 --> no longer supported

22.0.04.006 July 2025 --> supported

22.0.04.007 September 2025 --> current release

Single Sign On (SSO)

1.0.0: October 2023 --> no longer supported

1.1.0: April 2024 --> supported

1.2.0: April 2024 --> current release

Priority Definitions

Priority A

A problem where normal production or development work is no longer possible, or where production or development productivity is severely impacted, and where there is no workaround that can restore normal work with normal performance.

Priority B

A serious problem that does not meet the Priority A criteria.

Priority C

A minor problem that will be fixed at the discretion of the Jade Plant.

Release In Which Faults Are Addressed

The Jade Plant will fix a fault (PAR) in at least one of the following releases:

The next Major Feature Release.
The next Minor Feature Release.
The next Service Pack Release.
In a Hotfix for the current Service Pack Release.
In a Hotfix for the Service Pack Release in which the customer encountered the fault.

Notes:

Fixing some problems will involve RootSchema changes that require reorganisation of Jade application databases when installed. A reorganisation of this type has a major impact on all customers and therefore such changes are done only in Feature Releases.

In the next section, we refer to this type of fix as one that requires a structural change.

If a fault is discovered that is considered critical, a Hotfix will be provided for all affected releases, and all customers with support contracts will be notified.

Determining Where A Fault Is Addressed

The following guidelines are used to determine where a fault (PAR) is addressed. When a PAR is fixed, the closure details will state all releases for which the fix has been implemented.

If a fault has already been fixed in the current Service Pack release, then the customer will be advised by the Jade Customer Support Center (JCSC) to install the current Service Pack Release.
In the case of a Priority A fault for which there are no special circumstances preventing the customer from upgrading to the current Service Pack Release, the fix will be in a hotfix to the current Service Pack Release.
In the case of a Priority A fault for which there are special circumstances preventing the customer from upgrading to the current Service Pack Release, the fix will be in a hotfix to the Service Pack Release in which the customer encountered the fault.
In the case of a Priority B fault that requires no structural changes and is not dependent on new feature content, the Jade Plant will use its best endeavours to provide a fix in the next Service Pack Release.
In rare cases, a Priority B fault that requires no structural changes and is not dependent on new feature content may not meet Priority A criteria, but is still sufficiently serious that the customer may require a hotfix. In these cases, the customer must advise the JCSC of this requirement as early as possible (ideally in the initial Contact). Unless it is otherwise obvious from the Contact, they must also provide a description of the impact/urgency of the fault and state why a hotfix is required. The Jade Plant reserves the right to ask for more information to assess the hotfix request. If the request is accepted, a hotfix will be produced. Otherwise the Jade Plant will use its best endeavours to provide a fix in the next Service Pack Release.
In the case of a Priority B fault that requires no structural changes but is dependent on new feature content, the Jade Plant will use its best endeavours to provide a fix in the next Feature Release.
For any fault for which a fix requires structural changes, the Jade Plant will use its best endeavours to provide a fix in the next Feature Release.
Priority C faults will be fixed in the release deemed most appropriate by the Jade Plant.

New Features

Most often, new features are delivered in Major Releases or in Service Packs. The early release of any new feature is subject to careful risk assessment by the Jade Plant and takes the following into account:

Whether there is compelling customer demand and/or benefits from providing a feature earlier in the release cycle. If a new feature does not pass this test, it will not be included in the next release.
The degree of isolation of a feature. For example, new features that can be isolated entirely in their own schemas or libraries, or enabled only via configuration file options, can be included with minimal risk.
The risk of any unwanted side-effects. A new feature will be released early only when the risk of side-effects is acceptable in comparison to the benefits.

Any new features that are included in the next Service Pack will be documented in the Release Information.

Dispute Procedure

In the event that the customer and Jade Support cannot agree on the classification of a fault, then the issue can be taken to the Jade Development Manager for mediation. If resolution still cannot be reached, the issue can be taken to the Jade Software Corporation Director of Technology for a final decision.

Operating Systems

When an Operating System (OS) vendor ceases mainstream support for an OS, Jade support for that OS will cease with the next release of Jade.

Unless otherwise stated in the Operational Requirements, an Operating System is supported for the life of a release, including Service Packs.

The supported operating systems are:

Windows Server 2019
Windows Server 2022
Windows Server 2025
Windows 11

Virtual Environments

Jade will run in a virtual environment on all supported Operating Systems (see above) on Intel-compatible hardware.

Support will be provided as per the published release policy for faults found in a virtual environment. However, a problem that is suspected to be related to an issue in the virtualisation layer may result in requests for additional customer diagnostic actions. In some rare cases, fixes for issues that are specific to the virtualisation layer may need to be negotiated with the customer.

A more extensive discussion on the use of virtual environments and the associated environmental considerations and requirements is detailed in the "Environmental Considerations for Deploying Jade " white paper, and these requirements should be treated as part of this Release Policy.

Deprecated Features

As we review Jade and how it is used, we will occasionally identify features that could be decommissioned. Before doing so, we will create a JEDI for customers to comment on. These JEDIs are in development.

Access JEDI

Jade Platform Release Policy