Split versions SDKs according to semantic versioning industry standards and actively support major versions for 12 months post release.
What is semantic versioning?
Semantic versioning establishes a standard to uniquely name a particular release of an artifact. With semantic versioning, the unique label is made up by three components:
major version number,
minor version number, and
patch version number which assembled and separated by a period
.. The following summary is extracted from the specification referenced above.
When we release a new version of our SDKs, we increment the major, minor, or patch number. Which component is incremented depends on the change introduced and are separated by periods.
As is conventional in semantic versioning, we increment each according to the descriptions below:
Majorversion. When we make backwards incompatible API changes
Minorversion. When we add backwards compatible new functionality
Patchversion. When we make backwards compatible bug fixes
Additional labels for pre-release candidates and build metadata are available as extensions. These vary on a per language basis. Example include
Learn more at Semantic Versioning 2.0.
Adding new functionality
When Split introduces new functionality, it qualifies as a minor release. If that functionality is a breaking change or represents an API compatibility change, it qualifies as a major version change.
Fixing a bug
Bug fixes that preserve compatibility are released as a patch version. Depending on the invasiveness of the fix, the versioning is incremented as minor or major.
Split supports and patches prior major releases for up to 12 months following the version release date. If 12 months has elapsed, support and Split’s SDK engineering team may ask you to first upgrade to the current major release before attempting to patch old versions.
Article is closed for comments.