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 start at version 1.0.0. We follow Semantic Versioning (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:
EXAMPLE
  • 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

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.