Release Process

Release Process

Context

This project is published to Maven. There are two types of publications:

• SNAPSHOT: this kind of versions are used during the development stage. The version name must contain the suffix -SNAPSHOT. The same version can be published multiple times and the last publication overrides the previous ones. From the consumer point of view, importing a dependency with the version name <version>-SNAPSHOT will import the most recent publication, although specific publications can be imported using the whole form, such as <version>-20240111.113617-1.

  The list of snapshots can be checked in the Maven snapshot repository.

• RELEASE: these are the production releases. They can't be overridden and must be signed.

  The list of releases can be checked in the Maven release repository, which has a nicer UI in this page.

Version definition

The SDK version is defined in the Gradle version catalog always using the -SNAPSHOT suffix. This suffix is removed dynamically using a Gradle input parameter: ./gradlew publishToSonatype -PremoveSnapshotSuffix. This parameter is processed in the root Gradle script to strip the suffix out.

Code Freeze Phase

In preparation for the release, a "code freeze" phase begins to ensure stability and focus on bug and defect fixing. For having this phase started:

1. Create Release Candidate Branch

A branch is created from develop with the naming format upcoming-release-version-rc (e.g., 1.10-rc). This branch serves as the release candidate and will be updated with required fixes during this phase.

2. Update Version Name and Code

Update the SDK's version name and code to the upcoming release version. This change should be made on a new branch from and to develop and submitted via a pull request. Ensure the version code is correctly incremented, and the name follow the format new-version-SNAPSHOT (e.g., 1.11-SNAPSHOT).

3. Testing and Final Changes

During this phase, testing efforts are intensified, and only fixes to bugs and defects should be merged into the upcoming-release-version-rc branch (and also to develop branch); chore and feature tasks addressed during this period, would only go to develop branch.

This code freeze ensures a controlled and stable release process, minimizing last-minute issues.

Release process

Snapshots

Snapshot versions are automatically published on every push to develop. This publication is triggered by Jenkins (defined in the Jenkinsfile).

Additionally, they can be manually published using a Github action (Actions -> release.yml). If the action is trigger on a branch other than master or main, it will publish a snapshot version.

Releases

Release versions are manually published using a Github action (Actions -> release.yml). Release publications can only be published from main or master branch.

Typically, the release process in Maven involved multiple steps:

1. Publish to the staging repository (the dashboard can be accessed here).
2. Close the repository.
3. Release the repository.

There is plugin that allows to close and release the repository from code, so there is no need to access the dashboard. This plugin is used in the Github action so triggering the action is enough to publish the repository.

The publication might take some time to be available in Maven, usually around 20 minutes.