Those are real alpha releases, corresponding to some Docker image tags. I’d rather leave them in place unless there’s a real reason we need to nuke them… They mostly correspond to the entirely Maven version of the RefApp 3.x.
To me a beta is a release you could carefully roll out to production if you wanted. I don’t feel we are at this point yet but maybe I am wrong.
Regarding the release itself, I can look into preparing the necessary PRs. @ibacher do we need to specifically release fixed versions of the ESMs or we can simply obtain them from the import map of a running instance that has been tested?
You could even get something more convenient like this file that’s now part of the RefApp images and has all the versions in the same format that the openmrs assemble command (which builds the importmap) needs.
Just want to appreciate you guys for all the great work and knowledge sharing…I , and i’m sure many others, are following up closely and cheering you on! Great team please keep it up!
@ibacher we are going to go ahead with a double-commit for a release 3.0.0-beta.3. The only backend difference between beta.2 and beta.3 is Reference Demo Data that is being upped to 2.1.0 (from 2.0.0).
Following your convention the commits will be titled as such:
(release-reset) Reset to dev versions
(release) Create release commit for 3.0.0-beta.3
Note the full “3.0.0-beta.3” and not just “beta.3”.
So @ibacher be ready, we will need a beta.3 for the frontend image
So releases like this can now be done by tagging the (release) commit with the version number (no v, just 3.0.0-beta.3), which will create the necessary images.