Compatibility and Versioning

Understand which AuthOS release, API namespace, and TypeScript SDK these latest-only docs cover, and how to pin pre-1.0 dependencies safely.

AuthOS release 0.8.2 API v1 TypeScript SDK 0.8.0 Latest-only documentation
Updated Jul 15, 2026 Edit this page
On this page

These pages document the release, API namespace, and TypeScript SDK versions shown above. The site publishes one current documentation set; it does not provide archived version snapshots or a version selector.

What each version means

Label Meaning
AuthOS release The standalone and container release covered by deployment and operations guidance. Publication checks keep this value aligned with the latest public changelog entry.
API The HTTP route namespace documented under API Reference. It is not a promise that every pre-1.0 AuthOS release is wire-compatible.
TypeScript SDK The @drmhse/sso-sdk source version covered by SDK guides and reference pages. Publication checks keep this value aligned with the public package manifest.

Framework adapters and the CLI are separate packages. Check the package version you install rather than assuming it matches the TypeScript SDK version.

Pin pre-1.0 releases

AuthOS is Beta and remains in the pre-1.0 release series. Breaking API, configuration, SDK, or migration changes may occur before 1.0. Use an exact version for every runtime artifact and npm dependency; do not use latest, a caret range, or another unconstrained upgrade in a production manifest.

For npm packages, save the exact version shown by your package manager:

npm install --save-exact @drmhse/sso-sdk@<version>

For a standalone installation, use the exact AUTHOS_VERSION value in the deployment guide. Keep the lockfile, deployment manifest, and rollback artifact together.

Plan and verify an upgrade

  1. Read the public changelog and project status.
  2. Review the readiness roadmap for evidence and limitations relevant to your deployment.
  3. Test API calls, SDK behavior, configuration, migrations, and rollback in a representative non-production environment.
  4. Upgrade runtime artifacts and client packages together when release notes describe a compatibility dependency.
  5. Re-pin the verified versions and record the result before production rollout.

If you operate an older release, use the source and release notes tagged for that release. The latest-only site may describe behavior that the older release does not implement.