This document attempts to describe at a high level how and when the Azure SDK for iOS publishes new releases, as well as to document the specific steps that developers on the SDK team take in order to produce a new release.
The SDK versions and releases as a single artifact
The Azure SDK for iOS releases as a single artifact - all SDK libraries share a common version number and are all shipped together any time the SDK releases. This means that even if only a single library in the SDK has changes during a given milestone, when that milestone is released, all libraries receive a version number bump and are tagged and published. For an end user of the SDK, they should have the view that they are depending on a specific version of "the Azure SDK for iOS", rather than any individual library.
We take this approach because Swift Package Manager has a strong association between a repository and an artifact. The process of "releasing" to Swift Package Manager is simply to tag the appropriate commit in the repository. There is no way to tag different versions for different libraries within a single repository. So even though the libraries are published separately to CocoaPods, libraries must never be allowed to have inconsistent version numbers, nor is it permissable to publish a new version of a single library without publishing all other SDK libraries.
The SDK releases monthly
The Azure SDK team shares a common release cadence among all languages, shipping new releases at the beginning of each calendar month. The Azure SDK for iOS follows this cadence. In general, the team targets the first Friday of each month to be Code Complete, and the week thereafter as the release week. Any release that occurs during the release week is considered "in-band". On occasion, such as a critical bug fix or security issue, releases may also occur "out-of-band".
The release process
TODO
- Home
- Testing
- Release