Versioning

The browser SDK follows semantic versioning and is deployment-pinned.

Current release

Package: @opencloud/js
Version: 2.3.0
Stable module: /_opencloud/sdk.js
Stable types:  /_opencloud/sdk.d.ts

Every schema 2 or 3 app pins one installed version:

runtime:
  sdk:
    version: 2.3.0

The edge maps the stable module and declarations to that release. Application source always uses:

import { opencloud } from "/_opencloud/sdk.js";

When code needs to report the pinned browser SDK release, import the single public constant OPEN_CLOUD_SDK_VERSION from the same stable module.

Immutable artifact URLs exist for platform integrity checks, but app code and agent generators must not import them. Do not fetch /_opencloud/config, compare versions at runtime, guess a “latest” path, or construct a client.

Release policy

• Patch releases fix behavior without changing public signatures.
• Minor releases add compatible APIs and may tighten malformed-response checks.
• Major releases can replace APIs.
• A platform SDK release does not move an active app.
• An SDK upgrade changes runtime.sdk.version, creates a new app release, and must pass the full development and verification workflow.
• Rollback restores the earlier release and its SDK pin.

The package is platform-distributed and is not installed from npm.

The paired server SDK 2.3.0 adds the read-only http context for Function routes. Existing no-routes deployments keep their original SDK bytes and pin. Public CLI 3.11.0 understands the corresponding schema-3 route manifest contract.

The paired server SDK 2.6.0 adds the integration context and integration.emit for organisation-built integration providers that declare sync, webhook, or events, and gives integration failures the platform's own details, such as a calling-user slot's connectUrl. Browser SDK 2.6.0 is unchanged from 2.5.0 apart from its version.