There are several types of releases:

• "Module Release" - several need actual releases to get rid of "pre" https://github.com/openmrs/openmrs-distro-referenceapplication/blob/40c3f8309fa446c44ce0cdd8cbb9fc79aa19308c/frontend/spa-build-config.json#L30C1-L34C45 But they are stable. Need stronger release cadence around modules. 
• "RefApp Release": https://github.com/openmrs/openmrs-distro-referenceapplication/blob/3.0.0-beta.11/frontend/spa-build-config.json specifies the version of each . 
• "QA Release"
• "Tags": Moment in time snapshot - what the repo looked like at a particular point in time (points to a particular commit at a particular time where we released something)

When we "Release O3", there are 3 major things to do: 

( Step 0 is pushing to test3 for the pre-release testing)

1) Release the O3 RefApp in GitHub here

2) Update the O3 RefApp Docker Containers

3) Push the new O3 RefApp release to our "production" environment, the O3 Demo (environments shown below)

As Of July 2023

Step 1: QA RELEASE:

1. Obtain squad permission/buy-in to do a release. 

Task A: CREATE RELEASE PR

In 1 PR, 2 Commits are needed: (Example)

• 1) TO ADD VERSIONING: Release Commit: (release) Create release commit for beta.9' This fixes the version numbers. Because we don't want the test3 version to be deployed on dev3 because that could undo more recent changes. So, in dev3, we ignore any release with the string '(release'
  • Why: Pins a specific version # for all modules that were set as "next" or "SNAPSHOT". This is currently manual because there's still some human judgement and decision making for several specific modules. Example: https://github.com/openmrs/openmrs-distro-referenceapplication/pull/737/commits/f588d806c2511d71f419268d3631b1dfa98781a3 
• 2) TO PROTECT DEV3: Release-Revert Commit: (release-revert) Reset to dev versions Second Commit with release revert message that unsets the fixed version numbers. 
  • Why: Ensures 'main' branch gets back to state where it is still pointing at 'next', to preserve the cutting-edge state of the dev3 environment. 

Task B: ADD TAGS

Tag Release Commit with a tag named after the version number. 

Step 2: QA RELEASE (Automated)

Release is Triggered Due to the Tag AND Test3 is Auto-Rebuilt

"Distribution 3.x Releases" is only triggered by tags. 

1. Announce test3 release & version number to community in #openmrs.

Step 2: Manual Checks

1. Confirm that tests are passing satisfactorily in Test3. Using the O3 QA Spreadsheet is highly recommended, in addition to checking the automated tests. Go through both the Baseline Checklist and any checks specific to that release - so that new features get some review.  

Step 3: REFAPP RELEASE (Manual)

1. Go to the Deployment Project, "Deploy Reference Application 3.x"  (under the "Deploy" option in the menu)

2. Click the cloud icon for the QA build:

3. "Create new release" → Use the most recent build, and name the release one version number higher than the last one:

Deploy last successful build

1. Announce O3 Demo release & version number to community in #openmrs3 and on Talk. 

Note: You can see the history of releases here.