Published Feb 28

Releasing O3

3 min

O3 currently follows a release cadence of two weeks. This means we aim to publish new versions of our frontend to our QA environment(opens in a new tab) every fortnight. QA review and feedback typically takes a week, after which we promote the release to our demo Production environment(opens in a new tab). This cadence is subject to change as we get more experience with the process.

Steps of releasing O3

Cutting a new release of O3 typically includes three steps

  1. Cutting releases for the frontend modules

  2. Cutting releases for the backend modules

  3. Cutting the release for the ref app

1. Releasing frontend modules

Frontend releases are typically cut individually, for each module. Here’s how you can cut a release for a frontend module:

2. Releasing backend modules

Prior to cutting a O3 release, you must ensure that the backend module versions which are currently on a SNAPSHOT version must be released. E.g:- there cannot be lines such as <module.version>x.x.x-SNAPSHOT</module.version> in the distro reference application’s pom.xml file - https://github.com/openmrs/openmrs-distro-referenceapplication/blob/main/distro/pom.xml

1. Releasing a module on Bamboo

Before you update these versions, you’ll need to release such backend modules on Bamboo (instructions adopted from https://openmrs.atlassian.net/wiki/x/awSFAQ ).

  1. Find the bamboo plan for the relevant module.

  2. Check if the module has had a release recently (it might be that the module has had a release and the version just didn’t get updated in the ref app)

  1. Click the latest build to go to the build’s page to trigger a release.

Here’s an example PR where we updated these versions - https://github.com/openmrs/openmrs-distro-referenceapplication/pull/896

You can set the release version and the development version. If you are overriding the development version, leave the value empty as the script will automatically set it (make sure to check in the metadata section for the relevant build that the variables are what you want them to be, if they are, you don’t need to override these). If you don't override development version, it will be automatically set for you. If you are releasing 1.19.0, your next snapshot should be 1.20.0-SNAPSHOT, as per this discussion.

2. Updating the versions in the reference application

Once the backend releases are done, update their version numbers in the distro refapp repository.

Here’s an example PR that does that - https://github.com/openmrs/openmrs-distro-referenceapplication/pull/896

3. Releasing O3 to the QA environment

Once the step 1 and step 2 are released, you need to go to the Bamboo plan Create initial QA release - https://ci.openmrs.org/browse/O3-CQR and Run customized build

The o3.core.version should be set to the latest release of esm-core which you can find in here - https://github.com/openmrs/openmrs-esm-core/releases

The o3.release.version should be set to the new version of O3 that you want to release.

Once this plan finishes the build successfully, the version would be deployed to test3.openmrs.org. The build script would have automatically made a branch for this release as releases/x.x.x

4. Updating the QA environment

Say you’ve made some bug fixes, and you need to make some changes to the ref app itself. Make sure to add those changes to the respective release branch. Once the changes are merged in to the release branch, you’ll need to run the Bamboo plan Create updated QA release

 

Related content