Versioning Policy
SuprSend’s SDK versioning policy follows the Semantic Versioning (SemVer) standard. For example, in version 4.3.2, 4 is the major, 3 is the minor, and 2 is the patch.-
Major. Major. Introduces breaking changes that are not backward compatible. These may include renamed or removed methods, structural or conceptual redesigns, or change in underlying framework or library. Eg. Changing authentication mechanism in client SDKs.
Updating to a new major version typically requires code changes or migration. We don’t deprecate older versions support so you don’t have to worry about breaking changes in older versions. - Minor. New features that are backward compatible. Eg. Adding new methods or introducing more capbalities in existing methods.
- Patch. Backward-compatible bug fixes. Eg. Enhanced documentation with comprehensive in-app feed integration guides.
Support Policy
- All new features, performance improvements, and bug fixes are released on the latest major version of each SDK. Older major versions remain functional but do not receive ongoing updates or enhancements.
- While most releases are backward compatible, major releases may introduce breaking changes. In such occurences, we clearly mention this in changelog, documentation and provide migration guides to help you upgrade smoothly with minimal code changes.
- We recommend keeping your SDKs up to date to benefit from the latest security improvements, enhanced authorization mechanisms (especially for frontend SDKs), better performance, and access to new API capabilities.
- SuprSend’s release cycle is aligned with product development milestones, ensuring that SDK and API versions evolve together. This synchronization guarantees consistent behavior across the platform and minimizes the risk of unexpected breaking changes.
Migration Guides
We provide migration guides to help you upgrade from older major SDK versions. You can find them in our documentation:SDK Language and Framework Support
SuprSend SDKs are actively maintained across all supported languages and frameworks. We currently support all listed SDKs without any planned deprecations. In the unlikely event that a language or framework version is deprecated, we will provide advance notice and a clear migration path to ensure sufficient time for transition.Supported Versions
| Language / Framework | Minimum Supported Version |
|---|---|
| JavaScript / Node.js | 14+ |
| Python | 3.9+ |
| Java | 8+ |
| Go | 1.18+ |
| Swift | 5.0+ |
| Kotlin | 1.5+ |
| React Native | 0.60+ |
| Flutter | 2.0+ |
Release Policy
We follow agile methodologies to ensure rapid and flexible development. Roadmap Features: Features are released as soon as development and testing are complete, typically at a rate of ~1-2 per week. There is no fixed release day. We prioritize user feedback and market needs when planning feature releases. Backend SDKs: New versions are primarily released for new API additions or enhancements. SDK changes are generally backward compatible, except in case of major releases where breaking changes may occur. Major releases are communicated well in advance, and existing APIs remain supported for a reasonable transition period. Frontend SDKs: We incrementally add features in frontend SDKs such as Inbox, and release depends on our roadmap. Frontend updates focus on enhancing user experience and adding interactive capabilities. Bug Fixes & Improvements: Bug fixes are prioritized and released as soon as they are identified. Critical security fixes are released immediately, while minor improvements are batched for regular releases. Communication: Releases are announced on our Slack community, in-app and via email newsletters. Important features are also communicated directly in shared groups and all updates are logged in changelog.Best Practices
Pre-Upgrade Checklist
• Test in staging environment first
• Review changelog for breaking changes
• Backup your current implementation
• Verify all dependencies are compatible
Migration Steps
• Follow our detailed migration guides
• Update incrementally and test thoroughly
• Monitor application after deployment
• Have a rollback plan ready
💡 Pro tip: Start with patch upgrades before moving to minor or major versions to minimize risk.