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 - assembled and separated by a period
The following summary has been 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 below.
Majorversion when we make backwards incompatible API changes,
Minorversion when we add backwards compatible new functionality, and
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 will be incremented as minor or major.
Split will support and patch 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.