Reference Application 2.4 Release

I will go through and review the modules with my name on them–I have released many of them recently, so should be good to go.

Mark

2 Likes

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?

Take care, Mark

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)

I’m just releasing “as needed” at this point–if I do any more released before March 10th, will update the wiki page.

Mark

1 Like

Reference Applications need to be released for the 2.4 release. Issue tracking: https://wiki.openmrs.org/display/RES/Reference+Application+2.4+Release+Issue+Tracking

The following modules have not been released yet. reportingrest - @mseaton - reportingrest-1.6 reporting - @mseaton - reporting-0.9.9
metadatasharing - @raff - metadatasharing-1.2
metadatamapping - @raff - metadatamapping-1.1.0 idgen - @mseaton, @dkayiwa - idgen-4.3
dataexchange - @raff - dataexchange-1.3.2
coreapps - @cioan, @mogoodrich, @darius
registrationapp - @ddesimone, @darius, @cioan, @mogoodrich - registrationapp-1.5 referenceapplication - @wyclif, @mogoodrich, @darius - referenceapplication-2.4 referencedemodata - @darius, @raff - referencedemodata-1.4.2 referencemetadata - @dkayiwa, @darius - referencemetadata-2.4

Can module owners work towards completing these release?

1 Like

Module owners please take a look at this list and release them as soon as possible.

These modules have to be released before the main modules can be released and the UAT can begin

For completeness, @raff is currently looking into the problem that affects idgen, registrationcore, and registrationapp.

coreapps can’t be released until after reporting, idgen, and webservices.rest

I think the following modules are ready to be released now, so @mseaton or @raff, is there any blocker for these, or can you two push them out?

  • reporting, then reportingrest
  • metadatasharing
  • metadatamapping
  • dataexchange
  • webservices.rest (actually, can @pascal or whoever comment if this is really ready?)

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.

Thanks, Mike

@mseaton on a side note, the reporting module’s omod is around 14MB. Has it always been that big?

@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.

Mike

@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.

Fixed idgen issue in https://issues.openmrs.org/browse/IDGEN-49. We’ll need a small release of IDGEN with that fix.

Thanks @rafal for digging into this. I will take a look now, and if things look good, do the IDGen (and registration core/app) releases.

@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?

Thanks for thinking of me @mseaton. We’re using the latest released version of reporting currently.

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.

1 Like

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.

1 Like

@raff, can you keep https://wiki.openmrs.org/display/RES/Reference+Application+2.4+Release+Issue+Tracking updated with your progress in releasing modules?

2 Likes

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.

The release notes can be updated if the changes can be indicated by a one liner. https://wiki.openmrs.org/display/RES/Release+Notes+2.4

More extensive changes can be documented in JIRA under the appropriate sub-task of RA-1006.

By default, it is assumed that there are no changes needing to be documented, so in this case there is no need to do anything.

By default , you should be able to include JIRA search strings as attached in Reference Application 2.2 and 2.3 Release notes. I don’t think module owners would be able to track what changes are being done. Though if there are any major changes it would be beneficial to have them highlighted.