Jade Platform Release Policy

1. Purpose and Scope

This policy describes how Jade Software Corporation ("Jade", "we") maintains the Jade Platform and associated Jade Components. It covers the structure of our releases, how long each release series is maintained, how to request maintenance or support, and how we determine the release in which a fix will be delivered. 

This policy is reviewed periodically and may be updated.

2. Definitions

The following terms have specific meanings in this policy.

3. Version Numbering and Release Naming

3.1 Version format

Jade Platform version numbers use the format nnnn.n.nn.nnn. For example: 2025.0.01.005. The four components are: 

• Major Release: the first four digits identify the Major Release and represent the year of its initial general release. 
• Reserved: the second component is not currently used. 
• Release: the third component identifies the release within the release series. 01 is the initial Major Release (R1); 02 and subsequent numbers are Patch Releases. 
• Hotfix: the fourth component identifies the cumulative Hotfix level of the release.  

3.2 Rn release naming

Starting with Jade 2025, each release is identified using an Rn naming convention, where n is the release number within the release series. This aligns the release name directly with the third component of the version number. 

Release series prior to Jade 2025 use Service Pack (SP) naming, which is retained for those series. For example, Jade 2022 SP4 is version 2022.0.05.

4. Maintenance Lifecycle for Jade Platform Releases

We are committed to providing stable, secure and predictable maintenance for the Jade Platform. This section defines the maintenance lifecycle for a release series. 

4.1 Maintenance Period

Each release series is maintained for five years from the date of its Major Release. The five-year period is fixed at the date of the Major Release and does not restart when a subsequent Patch Release is issued. 

4.2 Release cadence

Within the maintenance period we commit to the following minimum cadence: 

• First 18 months: at least one Patch Release will be produced. 
• Years 2 to 4: at least one further Patch Release will be produced. 

Patch Releases are numbered sequentially from R2. Additional Patch Releases may be produced at our discretion. 

4.3 Fifth and final year

During the fifth year of the maintenance period, only the final Patch Release of the release series is maintained, and maintenance is limited to Hotfixes for Priority A Faults. Customers requiring maintenance during the fifth year must upgrade to the final Patch Release. The provision in section 11 for customers unable to upgrade does not apply during the fifth year. 

4.4 Identifying the final Patch Release

Because the fifth-year entitlement depends on which release is the final Patch Release for a series, we will identify the final Patch Release in the Release Information issued with it, and record it in Appendix A. Until a release is identified as final, customers should plan on the basis that maintenance for their release ends at the close of the fourth year. 

5. Upgrade Paths

Upgrades across more than one Major Release are not supported. For example, upgrading from Jade 2020 to Jade 2025 requires an intermediate upgrade to Jade 2022 before upgrading to Jade 2025. 

6. New Features

New features are normally delivered in Major Releases. Major Releases are the usual vehicle for new functionality; Patch Releases may contain selected features where the benefit outweighs the risk. The inclusion of a new feature in a Patch Release is subject to risk assessment by the Jade Platform engineering team. 

The assessment considers: 

• Customer demand and benefit: whether there is compelling customer demand or a significant benefit in delivering the feature before the next Major Release. 
• Isolation: whether the feature can be isolated from existing functionality, for example within its own schemas or libraries, or behind a configuration option. 
• Risk of side effects: whether the risk of unintended effects is acceptably low relative to the benefit of delivering the feature in a Patch Release. 

Any new features or functional improvements included in a Patch Release will be documented in the associated Release Information. 

7. Deprecated Features

As part of our ongoing review of the Jade Platform, we may identify features that are no longer required or appropriate for continued maintenance and support. Such features may be deprecated and subsequently removed from a future Major Release. 

A feature will be identified as deprecated in the Release Information for at least one Major Release before it is removed, so that customers have a full Major Release cycle in which to plan migration. The Release Information will describe the change and any available migration guidance. A list of deprecated features in each release series is maintained in the Jade Platform documentation. 

8. Jade Component Maintenance

Jade Components are products that integrate with the Jade Platform but are distributed and versioned separately. They currently comprise the Event Stream Producer, the Jade Data Refinery Event Stream Producer, Thin Client Single Sign-On, and Orb. 

For each Jade Component we maintain: 

• the current version; and
• the immediately preceding version (n-1)

Where a Component version is tied to a specific Jade Platform release series, the current Component version for each maintained Platform release series is also maintained. Versions outside this window are no longer maintained, and customers are encouraged to upgrade to a maintained version. 

Maintenance for Jade Components includes: 

• fixing known defects;
• maintaining compatibility with maintained Jade Platform versionsl
• maintaining compatibility with dependencies, such as .NET and Azure Event Hubs; and
• applying critical security updates.

Jade Components may follow a release cadence independent of the Jade Platform. Where a Component release depends on a specific Jade Platform release, the Component and Platform releases will be synchronised. 

The request, prioritisation and fault-handling processes in sections 9 to 12 apply to Jade Components as they do to the Jade Platform. 

9. Requesting Maintenance or Support

PARSYS is Jade's fault-management and customer contact system, through which customers raise and track requests. When a customer encounters an issue or requires support with the Jade Platform or a Jade Component: 

• Requests should be raised as a Contact or Fault in PARSYS, or by email to jadesupport@jadeworld.com. Most requests should initially be raised as a Contact. 
• The customer assigns an initial priority of A, B or C when raising the Contact. 
• If the customer believes the issue is a fault that may require a Hotfix, this should be stated clearly in the Contact, together with the impact and urgency of the issue. Where possible, providing a reproducer will assist with fault analysis. 
• If we determine that a Contact is a fault in the Jade Platform or a Jade Component, we will convert it to a Fault. 
• We may change the priority of a Contact or Fault at any time at our discretion. Where we do so, we will record the change in PARSYS. Priority changes may be disputed under section 12. 
• Routine Contacts are closed when resolved or when they become inactive. 
• If the request is for new functionality, we may recommend raising a Feature Suggestion instead. 

Target response and resolution times are not set by this policy. They are set out in the customer's support agreement. 

10. Priority Definitions

Priority A

A critical problem where any one of the following applies:

• Normal production or development work is no longer possible; 
• Production or development productivity is severely impacted, and no workaround can restore normal operation and performance; or 
• Data integrity or operational integrity is at risk. 

Critical Fault. A high-impact Priority A Fault that affects, or is likely to affect, multiple customers, or that presents a security or data-integrity risk, is additionally classified as a Critical Fault. Critical Faults attract the broader remediation described in section 11. 

Priority B

A serious problem that materially affects production or development work but does not meet the criteria for Priority A — typically because a workaround is available, or because the impact is confined to part of the system or to non-production use. 

Priority C

A minor problem with limited operational impact, such as a cosmetic defect, a documentation error, or an issue with a straightforward workaround. 

11. Determining Where a Fault is Addressed

The following guidelines determine the release in which a Fault will be addressed. When a Fault is fixed, the PARSYS closure details will identify all releases containing the fix. 

Some fixes require RootSchema changes, which in turn require customer application databases to be reorganised when the fix is installed. Because database reorganisation has a significant impact on customers, changes of this kind are made only in Major Releases. This constraint underlies several of the guidelines below. 

• Already fixed: if a Fault has already been fixed in the latest Patch Release of the release series, the customer will be advised to upgrade to that release. 
• Priority A — standard case: a fix for a Priority A Fault will be provided as a Hotfix to the latest Patch Release, provided there are no special circumstances preventing the customer from upgrading to that release. 
• Priority A — upgrade not possible: where special circumstances prevent a customer from upgrading to the latest Patch Release, the fix will be provided as a Hotfix to the Patch Release in which the Fault was encountered, and to any subsequent Patch Releases. Special circumstances are assessed by Jade in consultation with the customer.  
• Critical Faults: where a Fault is classified as a Critical Fault, a Hotfix will be provided for all maintained releases affected by the Fault. 
• Priority B — no structural changes: for a Priority B Fault that does not require structural changes and is not dependent on new feature content, we will make reasonable endeavours to provide a fix in a subsequent Patch Release of the release series. In rare cases a Priority B Fault may be sufficiently serious to warrant a Hotfix. The customer should notify Jade Support as early as possible, providing the impact and urgency of the issue and, where not otherwise evident from the Contact, why a Hotfix is required. If the request is accepted a Hotfix will be provided; otherwise, we will make reasonable endeavours to provide the fix in the next Patch Release. 
• Priority B — dependent on new features: where a Priority B Fault does not require structural changes but depends on new feature content, we will make reasonable endeavours to provide a fix in the next Major Release. 
• Structural changes: where fixing a Fault requires structural changes, we will make reasonable endeavours to provide the fix in the next Major Release. 
• Priority C: Priority C Faults will be addressed in the release considered most appropriate by the Jade Platform engineering team. 

12. Dispute Procedure

If the customer and Jade Support cannot agree on the priority classification of a Contact or Fault, or on the release in which a Fault will be addressed, the issue may be referred to the engineering manager responsible for the Jade Platform for mediation. 

If the issue remains unresolved, it may be referred to Jade's senior technology leadership for a final determination. This procedure does not limit any escalation or dispute resolution rights the customer has under its support agreement. 

13. Operating System Compatibility

Unless otherwise stated in the Operational Requirements, an operating system supported at the time a Major Release is issued remains supported for the life of that release series, including all Patch Releases in the series. 

Where Microsoft ends mainstream support for an operating system version, that operating system will not be supported in the next Major Release of the Jade Platform. Support for existing release series is unaffected. 

Supported operating systems

14. Virtual Environments

Jade is supported in virtual environments running on Intel-compatible hardware and supported operating systems. Faults occurring in a virtual environment are maintained in accordance with this policy. 

Where a fault is suspected to originate in the virtualisation layer or the underlying environment, we may require additional diagnostic information or customer testing to determine the cause. Issues specific to the virtualisation layer are outside the scope of Jade maintenance and may require resolution by the customer or their virtualisation provider. 

15. Related Documents

The following documents relate to this policy. They are maintained separately and may be updated between revisions of this policy. 

Appendix A: Currently Maintained Versions

This appendix records the current maintenance status of Jade Platform and Jade Component versions. It is updated with each release and does not require a revision of the policy body. 

Jade Data Refinery Event Stream Producer

Jade Platform

Dates in this table reflect the rule in section 4.3: releases other than the final Patch Release are maintained to the end of the fourth year of the series, and only the final Patch Release is maintained through the fifth year, for Priority A Hotfixes only. 

† Jade 2025 R3 has not yet been confirmed as the final Patch Release for the Jade 2025 series. If it is confirmed as final, its maintenance end date extends to Oct 2030. 
‡ Final Patch Release for the Jade 2022 series. Maintained from Nov 2026 through Oct 2027 for Priority A Hotfixes only. 

Event Stream Producer

Orb

Thin Client Single Sign-On