Reference application modules for release 2.4 have to be released by March 10th.
Can module owners release their modules or indicate that their modules are ready to be released in the following wiki page? https://wiki.openmrs.org/x/nYOtBQ
I’ve made my comments on the wiki–most of the modules already have a release with the latest changes, but there are a few with issues.
For what it’s worth, we’ve been trying to rely on non-snapshot versions of modules as much as possible within the PIH system which means much more frequent releases. The advantage of this is that most of the modules are ready to go. The disadvantage is that there is very likely to be further releases of modules before the final 2.4 Ref App release. Do we want to try to “lock down” the release versions to use in the 2.4 release based on which versions are ready to go today?
I would vote to use the latest version released by March 10th. (If you could give an estimate of what the version number would be, that would be great)
Thanks @darius, regarding reporting, my main concern is that there have been a lot of scattered changes since the last release, including:
The DbSession factory change
Several changes that were added, reverted, added back in later
A whole slew of GCI formatting changes, mostly to the README, but which clutter the commit history
A major commit to replace all hard-coded text values with message codes throughout the UI
A bunch of commits aimed at making the module compatible with 2.0, which moved a lot of code around
Almost all of these commits are non-functional changes, but which require regression testing to ensure that they haven’t broken any existing functionality. I have not done any significant regression testing myself. Given that this is for a major new release, and is not just an iterative new version to the module, ideally we would do a bit more rigorous testing to ensure the major functions and pages work as advertised.
Is there anyone using the latest 1.9.9-SNAPSHOT of reporting or who is available to do some regression testing of features? @arbaughj?
Once this is done, doing the actual release is easy and can be done by anyone with access to CI.
@dkayiwa, unfortunately yes. The vast majority of this is in dependent jar files, particularly POI (for Excel reading/writing), and a few others. You can have a look in the lib folder of the built omod to see.
@mseaton Not sure if this is of any value, but next week (Mar 21 - 25) the Uganda team will be in the field writing our very first reports with the reporting module, I could gently prod into using the latest 0.9.9-SNAPSHOT hope that it will provide some testing though under pressure.
@mseaton, would it work to do a “beta” release of the module" (basically, release to maven but not the module repo), so that we can get to UAT of the reference application sooner, and this UAT can presumably also help test the reporting module?
A quick update on the reporting module - I planned to get this out the door today, but ended up hitting an issue, which I have raised here: https://issues.openmrs.org/browse/REPORT-755. In trying to resolve this, I started making several minor UI fixes, which led to more and more, which I’ve collected in a branch (https://github.com/openmrs/openmrs-module-reporting/tree/remove-unused-code) and which I am doing under REPORT-754. I will likely try to merge this branch in for this release, but it is not critical. If anyone can take a look at resolving REPORT-755 early this week, that would be great.
I have an update as well… A new bug came up in MDS, which I need to address before releasing i.e. https://issues.openmrs.org/browse/META-345 I should be able to fix that tomorrow and do the release.
Metadatamapping has been released a few days ago. According to my knowledge there’s no need to release dataexchange. The last release was 19 days ago and no changes were committed since then.
Can module owners indicate what changes have occurred in their modules since Reference Application 2.3 as these have to be documented as part of the Reference Application 2.4 release process.