Support and versions

Support obligations are defined by your executed agreement. The SDK follows a published versioning contract, classifies reports by severity, and expects a fixed set of evidence so a production issue moves without a round trip.

Outcome

Your operations team knows which version it runs, what a supported upgrade path looks like, and how to raise an incident with the evidence already gathered.

Before you start

• A deployed customer SDK build
• A named deployment contact on your team

Done when

Your runbook records the deployed version, build fingerprint, and the escalation route for each severity.

Typical time

20 minutes

Versioning

The SDK follows semantic versioning.

Change	Version part	What it means for you
Breaking change to a public API	Major	An integration change is required before upgrading
New backward-compatible surface	Minor	Adopt when useful; no action required
Defect fix with no intended contract change	Patch	Verify the affected workflow after upgrading

The public API is the surface exported from @tradescript/pro and its documented subpaths. Anything reachable only through a deep import, a private entry, or a runtime internal is not public and may change in any release.

Pin an exact version in production. Test every upgrade against Verify your deployment.

Supported versions

The version supported for your deployment is the one recorded in your deployment record. Support for other versions, and the period over which a version remains supported, are matters for your executed agreement.

Fixes are delivered in a new release. Ask your deployment contact before planning around a backport.

Deprecation

A public API scheduled for removal is marked deprecated in its TypeScript declaration and noted in the release entry that introduces the deprecation. The replacement is named at the same time.

Deprecated surfaces are removed in a later major version, never in a minor or patch release.

Severity

Classify a report before sending it. Severity drives routing, not the wording of the message.

Severity	Definition
1 — Critical	A deployed production chart is unusable for most users, or a security defect is being actively exploited
2 — High	A major feature is unusable in production and no workaround exists
3 — Medium	A feature is impaired, or a workaround exists
4 — Low	Cosmetic issue, documentation defect, or a question

Suspected security defects follow Security regardless of severity.

Raising an incident

Contact your named TradeScript deployment contact. Include:

• the severity and the user-visible impact;
• the package version and the build fingerprint from dist/sbom.cyclonedx.json;
• the affected origin and whether it is production, staging, or development;
• the browser and version, and whether the issue reproduces in another browser;
• any structured SDK error code observed, from Errors;
• steps to reproduce, and whether the issue started after a change on your side.

Redact credentials, session tokens, personal data, and full account or order payloads before sending evidence.

Escalation

Ask your deployment contact for the escalation path recorded against your account. Confirm it during onboarding rather than during an incident, and record it in your own runbook alongside the deployed version and build fingerprint.

Next steps

Read Upgrades and rollback to plan a version change and keep a tested rollback release available.