Versioning and compatibility
How the Nirmos SDK keeps its public API stable over time.
The package is currently a pre-1.0 release (0.1.0). It uses semantic versions, but applications should review release notes closely while the public surface is still stabilizing.
- Patch releases fix bugs and improve internal behavior.
- Pre-1.0 minor releases can include public API changes.
- After a stable 1.0 release, major versions will identify breaking public API changes.
Documented surface
The following make up the current public SDK surface:
- package root exports
Nirmosconstructor options- product namespace names
- documented resource methods
- documented request properties
- normalized response properties
- error class inheritance and documented fields
HTTP wire formats, internal transport classes, cache implementation, provider payloads, and parser details are not public API. Nirmos can improve them without requiring application changes.
Extensible strings
Model identifiers, routing strategies, finish reasons, and stream event names can expand as the platform changes. Their TypeScript types preserve known autocomplete values while allowing future strings.
Do not write exhaustive code that crashes on an unknown provider, finish reason, or stream event:
switch (event.type) {
case "content.delta":
consume(event.delta);
break;
default:
// Ignore events this application does not use.
break;
}Additive response fields
Applications should read documented fields they need and ignore additional fields. Releases may add optional metadata or new event types.
Deprecation policy
When a public API must be replaced, release notes should identify the replacement and migration path. Do not assume a long deprecation window before 1.0.
Pinning
While the package is pre-1.0, pin the version deliberately:
{
"dependencies": {
"@nirmos/sdk": "0.1.0"
}
}Use a lockfile and automated dependency updates. Test SDK upgrades with representative chat, streaming, prompt, and embedding requests before production rollout.