Skip to Content
Web SDKOperationsVersioning

Versioning

@sladeid/slade-id-sdk follows standard semantic versioning. The current line is 3.x.

Pinning

A caret range is the intended pin:

{
  "dependencies": {
    "@sladeid/slade-id-sdk": "^3.3.0"
  }
}

That takes additive features and fixes automatically and never crosses a major boundary. Pin an exact version only if your release process requires a byte-identical lockfile across environments — you then own the upgrade cadence, including security fixes.

What counts as breaking

Always a major bump:

  • Removing or renaming an exported symbol.
  • Changing the wire format the SDK sends or the shape it returns — request bodies, response fields, error code values.
  • Changing a default quality threshold, since that moves which captures pass.
  • Narrowing an accepted input, or making an optional config field required.

What does not

  • New methods, or new optional config fields with safe defaults.
  • New members on an existing union, such as an added EnrollmentStatus value. Handle unions with an explicit fallback branch rather than an exhaustive switch you expect to stay exhaustive.
  • New error codes for new failure modes — including a narrower code on an existing error class where the class hierarchy is unchanged, so instanceof handling keeps matching.
  • New optional fields on a result type. Fields promoted out of raw into typed optionals are additive: raw keeps carrying them too.
  • Performance work, and internal refactors that leave the public surface alone.

Reporting the version you are on

The package exports the constant, and the HTTP client sends it on every middleware request as X-SDK-Version so server logs can be correlated to a build:

import { SDK_VERSION } from '@sladeid/slade-id-sdk';
 
console.log(SDK_VERSION); // '3.3.1'

Include it in every bug report — see Support.

Changelog

Each release publishes a changelog entry. A migration guide accompanies every major bump.

Troubleshooting