Versioning & Releases

Service Versioning

Individual services are versioned with a monotonically increasing version number that appears in the path, e.g. /developer/apps/v1. We typically create a new service version when making breaking changes to a generally available service, or otherwise significantly redesigning it.

SDK Versioning

We ship changes to the Upshift API weekly. Since the SDK is a client of many of our (independently versioned) APIs and distributed as a single package, we version the SDK using a calendar versioning scheme. This allows consumers to easily understand how up-to-date their SDK is compared to the evolving Upshift API.

We use a CalVer scheme of YYYY.MM.WW.MICRO. For example, the SDK released in the third week of January 2025 would have the version 2025.1.3.0. In situations where fixes need to be made to a weekly release, the micro version is incremented, e.g. 2025.1.3.1.