Release process

Azure SDK for Java release process

The goal of this document is to create an outline of the release process for the Azure SDK for Java team. It is meant to act as general guidelines and ordering of steps needed to be taking during a release cycle.

Before release

Before triggering the release pipeline a PR must be submitted to update the CHANGELOG and README for each module being released. The CHANGELOG's latest release tag needs to be updated to match the releasing library version and the date it is being released. The README's Include the package section needs to be updated to list the version of the library being released, in addition to that this is a good time to do a quick review of the README for typos and other grammatical mistakes.

After the PR has been merged you'll need to validate that all upstream releases are complete, refer to the release order to view the release hierarchy.

Releasing

Once all prerequisites for releasing a library is met you'll want to trigger the release pipeline to run. When the pipeline requests the modules to be approved for release you'll want to download the generated artifacts. These artifacts should be used to run a simple application that validates that they were generated correctly. After validating the generated artifacts, approve the modules being released and wait for the pipeline to release them to Maven.

Post release

As each module is released to Maven GitHub will generate a Release, use this release to finalize the release tracking information in Azure Pipelines. The aliased URLs in the release generated by GitHub should be used to fill out all information requested in the Azure Pipelines release tracking. Once all information is filled out the release will be ready for doc generation, at this time assign Scott Beddell as the assigned person for the feature in Azure Pipelines release tracking feature.

At the same time Azure Pipelines will generate a version increment PR. You should assigned this PR to yourself and get it merged in.

Release order

Release order is based on dependency ordering, therefore when releasing a library you must wait for upstream to release and merge in their version increment PR. There is a caveat when an upstream library is doing a beta release but the downstream library is doing a GA, in this scenario the dependent library will maintain a dependency on the latest GA release of the dependency library and may also ship ahead of upstream (or at the same time).

NOTE: It is safe for the version in the downstream library to increment to the release version as we test this scenario during every PR validation and during the nightly test runs. The From Source pipeline is the one that validates this.

The Azure SDKs for Java uses the following release order.

1. Core libraries

The Azure Core libraries are the root dependency which all other libraries are building on top, this MUST be the first libraries shipped.

2. Identity

Azure Identity is another common dependency that should ship after Azure Core and SHOULD ship before everything else. Identity is a loose requirement here as there are special rules where Identity cannot be included as an explicit dependency and is completely optional based on the consumers discretion.

3. Everything without another library as an upstream dependency

This is the bulk of the Azure SDK libraries, once Core has shipped and the release version is taken these libraries may ship at will. These don't include dependencies on other libraries outside of their library group (Storage libraries share a common library but all will be shipped at once).

4. Anything with another library as an upstream dependency

These are the last libraries to ship as they contain another non-Core library as a dependency. An example of this is EventHubs Checkpoint Store Blobs which has a dependency on Azure Storage Blobs. This must wait for Azure Storage Blobs to release to prevent any diamond dependency issues such as it and Blobs having different Azure Core dependencies.