SOFTWARE RELEASE LIMITATIONS

Software release limitations allow you to control which software versions a customer is entitled to use. In practice, they support two related goals:

• Upgrade compliance: controlling whether a client is allowed to install or activate a newer software version based on the customer’s licensed entitlement

• Deprecation compliance: identifying clients that still run outdated or deprecated software versions

CREATING SOFTWARE RELEASES

To use software release limitations, first enable Software Release Limitations in the product’s advanced settings.

Software releases are managed in the Releases tab of the Product section in the SLASCONE portal. Whenever a new software version should be considered for licensing or compliance checks, add it to the list of available releases.

Supported formats include 12.0, 12.0.1, or 12.0.1.3, meaning numeric fields separated by one or more dots.

UPGRADE COMPLIANCE

In many licensing scenarios, customers are allowed to continue using a software version they already licensed, but they are not entitled to newer versions released afterward. Software release limitations support exactly this scenario.

For this purpose, a license can define an optional Maximum Software Release. This value represents the highest software version the customer is authorized to use. Any version above that limit is treated as non-compliant.

ASSIGNING A SOFTWARE RELEASE LIMITATION TO A LICENSE

As long as the customer is entitled to receive updates, the license typically does not require a software release limitation. Once that update entitlement ends, for example after cancellation of a maintenance or update contract, the license should be updated with the highest software version the customer is still allowed to use.

During the next activation or heartbeat, the client’s software version is then validated against this license-specific software release limitation.

The response includes both the compliance result is_software_version_valid and, if applicable, the assigned software release limitation:

"is_software_version_valid": true,
"software_release_limitation": {
  "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "product_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "software_release": "21.1",
  "description": "string"
},

By default, this compliance result is returned as part of the normal activation or heartbeat response body. Alternatively, you can configure the edition to return an HTTP 409 Conflict response instead (Error Id: 1003) when the client version is not compliant.

This behavior is controlled by the following edition property:

EXAMPLES

If a license has a maximum software release of 22, the following applies:

• 21.X compliant and can be activated

• 22.X compliant and can be activated

• 23.0 non-compliant and cannot be activated

• 23.1.5 non-compliant and cannot be activated

Although major versions are the most common approach, SLASCONE can also evaluate minor versions and revisions. For example, if a license has a maximum software release of 22.1, the following applies:

• 21.X compliant and can be activated

• 22.0 compliant and can be activated

• 22.1 compliant and can be activated

• 22.1.5 compliant and can be activated

• 22.2 non-compliant and cannot be activated

• 23.0 non-compliant and cannot be activated

• 23.1.5 non-compliant and cannot be activated

DEPRECATION COMPLIANCE

In addition to license-specific upgrade control, SLASCONE can also enforce a product-wide minimum supported software version.

This allows you to identify or react to clients that still run deprecated versions, even if those versions are still permitted by the customer’s license.

When a client performs a license activation or heartbeat, the licensing server:

1. Checks whether the product defines a minimum supported software release

2. Compares the client’s current version against that minimum

3. Returns enforce_software_version_upgrade = true if the client version is below the minimum

4. Allows the client application to warn the user or enforce an upgrade programmatically

This is different from is_software_version_valid, which checks compliance against the license-specific maximum version rather than the product-wide minimum version.

BEST PRACTICES

• Use the license-specific maximum software release to control upgrade entitlement

• Use the product-wide minimum software release to identify or phase out deprecated client versions

• Make sure the client application evaluates both is_software_version_valid and enforce_software_version_upgrade where relevant

• Keep the product’s release list up to date whenever new software versions become commercially or operationally relevant