There will always be a need to push changes to our API and various SDKs. Here we present some information on how we handle these.
API
We never intend to push breaking changes to the API and always strive for maximum backward compatibility if we do change something. On the rare occasions when we do make a change to the API (we have done so several times in the past) and we suspect it may be breaking for a sub-set of customers, our engineers do extensive quantitative research on our customers who might be affected by querying our logs for requests that will be affected by a change. From there, our Customer Success and technical support team will reach out to explain the changes. Ample time will be given for changes to be tested and deployed and we provide as much support as possible during this time.
SDKs
Our SDK teams follow Semantic Versioning (semver 2.0) for releases. This means that breaking changes will be clearly detailed in major releases of SDKs and minor versions will include bug fixes, performance improvements, and polishing.
Our SDK team leads recommend keeping up to date on minor versions as much as possible and upgrading major versions within 3-6 months of release. Our teams do our best to provide support for previous versions, but eventually, maintenance on previous major versions will stop.
Release Cadence
The SDK teams typically release minor version updates approximately every 2 weeks for the UI component library SDKs. For the low-level client SDKs, the releases are less frequent and typically updated when a new feature is released or a dependency is updated.
Comments
0 comments
Please sign in to leave a comment.