O3 and 3.0.0: It's time to say Goodbye to the Beta

Dear Community,

We’d like to propose releasing RefApp 3.0.0 without the beta label - or as it shall gradually become known: RefApp = the “Community distro-emr”. (since we are moving outside of this being a suggestion/“reference” and more into “this is an out of the box product we maintain together”; notes from the TAC discussion about this here.)

We have heard a lot of feedback from highly active O3 contributors who feel it is high-time that we had an official RefApp release, especially given that O3 is already live in production in many facilities (though in various forms with various configurations of modules).

Based on the strong opinions of active O3 Community Members, we believe the previous reasons for delaying 3.0.0 non-beta (described below) should no longer hold us back, and instead we can continue moving forward on these must-do things, it will just be through non-beta releases. In the meantime we are finding that still having the “beta” tag is eroding confidence in our shared work, even though the actual O3 apps (esm modules) already have non-beta versions and have for a while!

How do we propose we do this?

  • This is actually the exact same as 3.0.0-beta.21, just with a different name - no functional changes to the frontend or backend (okay, the queue module got a bump with no functional changes). (Note: the frontend contents of the beta.21 release were exactly the same as beta.20. Beta.21 was a copy of beta.20 just with a few backend module updates.)
  • Thanks to @dkigen and @jayasanka and @ibacher for helping prep the release 3.0.0 PR (not yet merged!!), see here:

Why Not Sooner?

The reason we had been delaying the 3.0.0 release was because we had been hoping to wrap up these 3 things first:

  1. O3 Setup improvements that will make running and configuring O3 easier (i.e., all the high priority issues better documented than ever in this new-ish Epic) - we still plan to get this done ASAP. We want people to have a great experience in running the RefApp on their machine for the first time!
  2. Thorough support for RDE (Retrospective Data Entry) - There are several community initiatives underway for this:
    • i.Design Improvement of the Past Visits page - the UX Design process led by @pauladams is currently wrapping up user testing and I expect development by @PIH and @Mekom to begin soon.
    • ii. The Bulk RDE feature called “Fast Data Entry” contributed by @ICRC is an awesome feature but experienced regressions. ICRC is currently investigating having additional members fix this in the RefApp/distro-emr for everyone to benefit from again. Adoption of this app is halted for now because of this fix need, and because it was using the Angular Form Engine.
    • iii. A whole epic around RDE Improvements to existing UI that got stuck in a twilight zone pending the Design Improvement contract and subsequent work in (i).
  3. Completion of An Assortment of Bugs We Want to Fix:

Obviously I share the concerns of everyone who wanted to see these 3 things done a while ago, and personally I would strongly prefer that all of these were already addressed - but of course we have to work with the resources we have and the reality that implementers’ timelines to deliver on certain features are often impacted by other, unforseen critical priorities in their implementation work.

I hope this makes sense and let’s discuss on this week’s O3 Squad call together!


p.s. - we have also updated the Timeline view at https://om.rs/o3timeline to correctly show the recent past and near-future planned O3 releases.


Thank you so much to the 40 people who joined today’s O3 squad call (wow!) representing 8+ community organizations!! (PIH, UCSF, Mekom, METS, Madiro/MSF, UW DIGI, Sonder, Palladium, OpenMRS Inc, ICAP-ET)

The above plan to release 3.0.0 got a unanimous approval (and many :tada: emoji’s), with the minor change to include the newer version of Initializer (this should not impact the previous QA done related to beta.21). @dkigen @jayasanka and myself will follow up on this today; if we can’t get the Iniz version released today then we hope to get this released early next week.

We also had unanimous buy-in to the proposed next release cut-date of this time (Thursday) next week for 3.1 :tada:

Thank you everyone!! :heart:

1 Like

@corneliouzbett / @mksrom / @ruhanga the above means that we need to release Iniz 2.7.0 as soon as possibly can.

1 Like

:heavy_plus_sign: 1, absolutely!

@dkayiwa / @ibacher, let’s use the opportunity of this major release point to change the Maven coordinates to


On this model set with openmrs-distro-his and as discussed recently.

1 Like

@mksd How important is this? If we do this I need to do a new breaking release of the SDK first.

It’s only as important as the importance of naming consistency.

If it’s a rabbit hole that induces many changes and extra work… then I understand that folks would rather leave it out.

1 Like

I agree this should happen, but also agree it’s not worth delaying the release for. We can aim for 3.1 or 3.2, depending on the scope of lift :slight_smile:

It’s already done, so…


That’s really awesome. @grace, as discussed with @ibacher on Slack (here), the last bit is to actually rename the repo to openmrs-distro-emr (from openmrs-distro-referenceapplication).

1 Like