# Versioning Policy

> Click here for information on Dropbox Sign's SDK versioning policy, which the API engineering team follows to ensure safety, reliability, and transparency.

# OpenAPI SDK Versioning Policy

This page outlines Dropbox Sign's approach to versioning and support for official SDKs. It may change over time as we evolve to meet customer needs.

## Versioning Strategy

All SDKs powered by our [OpenAPI specification](https://github.com/hellosign/hellosign-openapi) start at version `1.0.0`. We follow [Semantic Versioning](https://semver.org/) (SEMVER), where SDK changes increment the version according to the following structure: `MAJOR.MINOR.PATCH`.

* `MAJOR` - introduces change(s) that are **not** backwards compatible.
* `MINOR` - adds functionality that is backwards compatible
* `PATCH` - contains bug fixes that are backwards compatible

Additionally, a `LABEL` can be used as an extension to the `MAJOR.MINOR.PATCH` format. For example: `1.0.0-beta1`.

### Keeping SDK Versions in Sync

Some SDKs are used internally by the Dropbox Sign team for testing purposes and may increment more quickly than other SDKs. In order to keep the SDK versions in sync, some SDKs may occasionally add a `BUILD` identifier.

The version format in those situations is `MAJOR.MINOR.PATCH.LABEL[BUILD]`. Here is an example of how that might look:

<Info title="Example" icon="fa-light fa-circle-exclamation">
  * Pretend that every SDK is currently at `1.1.0`
  * PHP SDK version bumped to `1.2.0-beta153`
  * PHP SDK version bumped to `1.2.0-beta154`
  * **Every SDK** (including PHP) version bumped to `1.2.0`
</Info>

## Version Support

We will support and patch prior `major` releases for up to **12 months** following the release of a new `major` version. For example, after the new `1.X.X` Node SDK is released, we will provide security updates and and fix critical issues for the legacy `2.X.X` Node SDK for 12 months. After 12 months, the previous `major` version of the SDK version will no longer be supported.