Partner Release Process

1. Prior to release, ensure all relevant code is checked into main and any necessary binaries are published to support release.
2. Create a PR in the azure-sdk-for-ios repo that bumps relevant versions using python eng/scripts/version.py update <old_version> <new_version> <MODULE>. Ensure the PR branch is off the main repo and not a fork. Use the branch name <MODULE>_<version>. Naming the branch in this way allows you to use the tag parameter in files before actually creating the tag in Github.
3. Do a fresh pod install of the AzureSDKSmokeTest project and verify that it builds without any errors. Set the PODSPEC_BRANCH to the release branch before running pod install. You should test installation with the environment variable POD_LINKAGE set to "dynamic" and "staticframework".
4. With approval from the AzureSDK team and a passing CI, merge the PR. Note: Do not delete the branch at this point. The CI will need this branch when you queue the internal build in the next step.
5. In the internal Azure Devops pipeline, queue a manual build of your service's pipeline (ex: ci - communication). You must have permissions to queue manual builds. This unlocks the automated release pipeline.
6. Once the first stage of the build has passed, you can delete the version bump branch. It is preferable to do this now as it is more difficult to do once a tag is created in the next step with the same name.
7. Once the first stage of the pipeline has passed, the second Release stage awaits approval. For service branches with multiple SDKs (ex: communication) ensure you only approve the release of your SDK. Do not touch any other SDKs. You will need specific permissions to approve the release of SDKs.
8. Approving the release will automatically create the necessary tag in the azure-sdk-for-ios repo, will publish to CocoaPods, and will sync the SwiftPM mirror repo and tag it appropriately.
9. Contact the SDK team to update the generated Jazzy docs.