-
Notifications
You must be signed in to change notification settings - Fork 63
Release Process
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>-SNAPSHOTwill 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.
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.
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:
- 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.
- 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).
- 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.
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.
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:
- Publish to the staging repository (the dashboard can be accessed here).
- Close the repository.
- 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.
With each major, patch and hotfix release, the new features and bugfixes are listed alongside the code. Currently, a preliminary list is generated using the project management tool Jira for bugs and features, while updates in the libraries and breaking changes are manually added. The finalized list is published when the new version is released and announced.
There are two DHIS2 portals where the SDK documentation for developer is publised: The developer portal and the DHIS2 documentation page. The source files for these portals are located in the docs/content/developer directory, and are updated before each release.
Additionally, the public API documentation is published via Github Pages and can be accessed here. This page is automatically generated and published whenever there is a change in the master branch using Github actions.