Deprecation policy
You should be able to build on Navapatra and not have to revisit working code on our schedule. These are the commitments.
API versions
Section titled “API versions”- Breaking changes only ship in a new dated version. What counts as breaking is listed in Versioning. Your pinned version keeps its schema and conventions.
- At least 12 months of notice before any API version stops being served. The notice appears in the changelog with the retirement date and what to change.
- During the notice period the old version keeps working exactly as before, including data updates.
- After retirement, requests that name the retired version in
Navapatra-Versionfail with400 unsupported_version. Move your pins and headers during the notice period.
Data updates
Section titled “Data updates”Time zone database releases, Bikram Sambat table updates, Samiti tithi overrides and holiday data are corrections, not API changes. They apply to every supported version without notice periods, because keeping wrong data would be worse. Each update is announced in the changelog with the meta version it changes (tzdbVersion, bsTableVersion or overridesVersion), so you can find the responses it affects.
Fields and parameters
Section titled “Fields and parameters”When a field or parameter is replaced within a version (for example, a better-named field is added), the old one keeps working for the life of that version. It is marked deprecated in the API reference and in the changelog, and is removed only in a later dated version.
SDKs and widgets
Section titled “SDKs and widgets”- SDK and widget packages follow semantic versioning.
- The two latest major versions are supported with fixes.
- A major version is supported for at least 12 months after its successor is released.
Endpoints in beta
Section titled “Endpoints in beta”Endpoints marked beta in the reference may change within a version, with notice in the changelog. Nothing is marked beta today.