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:
- 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!
- 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).
- 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!
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). 
1, absolutely!