Skip to main content

Legacy v1 licensing removed in 3.1.6

· 3 min read
Jeremy Scott
Co-founder

BREAKING CHANGE: Opscotch 3.1.6 removes legacy v1 licensing completely.

3.1.5 was the final release that supported v1 licensing. While the 3.1.5 agent runtime continued to support apps packaged with a legacy license, the remaining hard dependency was in the test runner, which still needed a legacy license to start.

From 3.1.6 onward, legacy v1 licensing is completely removed.

What changed​

In practical terms:

  • v1 licensing has been removed from the supported 3.1.6 runtime path
  • apps packaged with the legacy license will not run on 3.1.6 and must be repackaged for the current model
  • production licensing should be issued and managed through the current licensing flow
  • packages and deployments should be validated against the current runtime licensing model before upgrading

Test runner behavior​

The 3.1.6 test runner experience is now license-free when running against a development agent runtime.

That works because the development agent automatically generates a development license. For local development and normal test runner use, you no longer need to supply a legacy license just to start the test path.

Production testing is intentionally different.

When running tests against a production agent runtime, a production license still needs to be supplied. Set OPSCOTCH_TEST_PROD_LICENSE and OPSCOTCH_TEST_PROD_LICENSE_KEY when starting the test runner. This follows the Opscotch policy that the production runtime should not be weakened for testing convenience. Tests that target production behavior should use the same licensing expectations as production deployments.

Why it changed​

The current licensing model separates licensing from package rebuilds.

Instead of treating a license as something that must be embedded into every packaged app, Opscotch now supports delegated runtime licensing. Licenses can be issued through the licensing service, delegated down to the right operating level, and served to runtimes by a licensing app.

That model is a better fit for:

  • customer-managed licensing
  • vendor-managed licensing
  • managed-service environments
  • production and non-production separation
  • changing entitlements without rebuilding application packages

Removing the v1 dependency lets the runtime and test runner move forward with one licensing model instead of carrying two operational paths.

Upgrade impact​

If you are already using the current licensing flow, this change should mostly be a cleanup in the runtime and test runner behavior.

If you still have deployments or packaged apps that depend on v1 licensing, upgrade them before moving to 3.1.6. The important step is to make sure runtime licensing is provided through the current license model rather than through the legacy v1 path.

Before upgrading production deployments, check:

  • how the deployment obtains runtime licensing
  • whether the license is production or non-production
  • whether the runtime can reach the configured licensing host when one is used
  • whether package and runtime licensing expectations match

For the current licensing model and operational setup, see: