Releasing O3 Ref App 3.0.0-beta

Software Reference App
,
1

@achachiez and @ibacher this is my suggestion: someone to make a PR that we will merge rebase and that contains two commits :

  1. First commit title: Release 3.0.0-alpha
  2. Second commit title: Resuming development: 3.0.0-SNAPSHOT

Commit Release 3.0.0-alpha:

  • All ESMs should be frozen to what next points to now.
  • The distro version should be 3.0.0-alpha.
  • There shouldn’t be any snapshots left (that’s already the case).
  • This commit should be tagged 3.0.0-alpha.

Commit Resuming development: 3.0.0-SNAPSHOT:

  • This should basically revert the above:
    • All ESMs should reset to next.
    • The distro version should reset to 3.0.0-SNAPSHOT.

@ibacher as an aside I just saw that there was a bunch of 3.0.0-alpha tags already, what are those? Can we remove them?

2

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.

3

So should this one be 3.0.0-beta then?

4

Or just 3.0.0-alpha.10…

5

The reason why I suggested the upgrade to beta is because here we have at least fixed all Maven artifacts, what do you think?

6

Yeah, I think it’s fine to start calling it a beta release…

7

So this will be either 3.0.0-alpha.10 (why 10 @ibacher, as way to start a new “serie”?) or 3.0.0-beta.1.

@achachiez seemed to prefer to stay on alpha still, could you elaborate why?

8

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?

9

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.

10

Remember that you also have the release candidate: 3.0.0-alpha → 3.0.0-beta → 3.0.0-rc → 3.0.0. So we have some wiggle room.

@burke @dkayiwa since you’ve overseen this a million times for Core, what’s your take here?

11

This is the rough guideline that we have used for the core platform: OpenMRS Platform Release Process - Documentation - OpenMRS Wiki

If there are no major bugs pending, then we could proceed to beta

1 Like
12

@achachiez let’s make this 3.0.0-beta.1 then.

13

@mksd @ibacher here is the PR Release 3.0.0 beta.1 by enyachoke · Pull Request #672 · openmrs/openmrs-distro-referenceapplication · GitHub

1 Like
14

Thank you!

This was rebase-merged: here are the two commits Release 3.0.0 beta.1 by enyachoke · Pull Request #672 · openmrs/openmrs-distro-referenceapplication · GitHub

The second commit undoes the release commit, so there is no changes on main.

@ibacher @raff we have a tag 3.0.0-beta.1 with no moving parts (fixed Maven versions, fixed ESM versions) here: Release 3.0.0-beta.1 · openmrs/openmrs-distro-referenceapplication@b16447c · GitHub

15

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!

16

@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 :muscle:

Cc @grace

2 Likes
17

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.

18

Cool, so simply pushing a tag triggers a front-end release?

19

It should, yes.

1 Like