Help Test Reference Application 2.4!

@jdegraft now that the testing is done and all is well, do you think you can proceed with the next steps to release?

@dkayiwa, I will proceed with the next steps towards releasing Reference Application 2.4. Thanks for your help.

@jdegraft how is this going? Are you blocked at anything?

What OpenMRS version will the Reference Application be based on 1.11.6 or 1.11.7 (currently in SNAPSHOT)?

@dkayiwa, will start working on the final release this weekend.

@ssmusoke, ref app 2.4 runs with 1.11.5.

@dkayiwa, @burke, could not sign in to the wiki to get the instructions for the final release. I created a case with help desk. I will release the following weekend after I can see the instructions on the wiki.

@jdegraft, you shouldn’t need to “sign in” to see the release process instructions. All the pages should be public.

@darius, it turns out even though I was getting an error, I was successfully logging in. I will proceed.

@darius, the instructions are not clear about releasing the modules.

According to my understanding the only modules waiting to be released are referenceapplication and referencemetadata. As the instructions indicate these are in SNAPSHOT in the distro pom.

However in the distro pom adminui and uitestframework are also in SNAPSHOT which the instructions indicate means they have to be released as part of the final release process. However these modules should already have been released. In other words I don’t know what to do about these.

Also, to update the distro pom, do I have to make a pull request?

I was hoping to finish the release this weekend and work on the release documentation maybe the following week. Any guidance will be appreciated.

UPDATE @darius, @burke, @dkayiwa Checking as per release instructions, the distro pom is completely out of sync with the 2.4 release. Some modules have versions ahead of those in the release and some have versions used in 2.3 release. I have a list of the modules which are out of sync.

Considering the distro pom is used in current builds, how are we going to update the distro pom. In particular emrapi for 2.4 release uses 1.13 and the distro pom uses 1.14. Since this module is central changing the pom may break existing builds.

@jdegraft, thanks for checking how to approach this, instead of going blindly ahead! :slight_smile:

I don’t know offhand why it’s this way, so I’ll investigate (and explain in detail what I’m looking at).

We look at the github history of the pom.xml file in the openmrs-distro-referenceapplication module: https://github.com/openmrs/openmrs-distro-referenceapplication/commits/master/pom.xml

First, searching for “uitestframework”:

  • The most recent two commits are relevant.
  • On March 12 I did a release, and made the distro use the released version
  • On March 17 @leebreisacher updated to the latest snapshot.
  • So we need to investigate further by looking at the openmrs-contrib-uitestframework repo to see what happened between March 12 and March 17, and whether Lee did this on purpose (i.e. whether we need the new changes, or should revert to the latest released version). I see that on March 13 Lee made a bugfix, and I guess he applied to the distro a few days later.
  • Therefore we should release a new version of uitestframework. I will do this.
  • [UPDATE] I did this, and updated the pom.xml file. But I realized I built the release with Java 8. Hopefully this doesn’t break anything!

(At this point I see that you’ve edited your post with some more details, so I’m going to post this now.)

Please share the list of differences.

I assume that what has happened is that people have, for various reasons, released new versions of some modules (and this automatically incremented the version of them that’s included in the distro). Usually this won’t happen during the time we’re testing and doing a release (since it’s only a few weeks) but this time because of all the slowdowns, it has taken much longer, so it’s not surprising that modules have been released.

We should not revert the distro to include older versions of these modules. Instead we should update our notes about the refapp 2.4 release, and release it with these newer module versions. (If you feel it’s necessary to do further testing, we can. However these newer module versions have been on the int and qa servers for >1 month, so I would assume sufficient testing has been done already.)

Now, continuing to investigate the snapshot versions, looking in the distro’s pom.xml for adminui, I updated it to the snapshot on Feb 9 in this commit.

I guess that nobody actually released the adminui module during the refapp 2.4 release process (as the only released version is 1.0 from September 2015).

So someone should go ahead and release the adminui module. @wyclif, do you want to do this, as you’re the unofficial owner of this module? (If you don’t have time to do it this weekend and that’s going to block @jdegraft from doing the refapp release I can try to release adminui tomorrow.)

The 1st version is the release the 2nd version is the bistro

I would like to highlight web services.REST we used 2.13 for the release because according to @raff, 2.14 required platform 1.12 or something to that effect and in the distro it is 2.14.

This part of the list is where the release is behind the distro

Event - 2.3, 2.4

EMR API - 1.13,1.14

Reporting - 0.9.9, 0.10.0

App UI - 1.5, 1.5.1

Rest Web Services - 2.13, 2.14

This part of the list is where the release is ahead of the distro

Provider Management - 2.5, 2.4

UI Library - 2.0.5, 2.0.4

Calculation - 1.2, 1.1

HTML Widgets - 1.7.1, 1.7.0

Metadata Deploy - 1.8, 1.5

Metadata Mapping - 1.1.0, 1.0.2

UI Commons - 1.8, 1.7

HTML Form Entry - 3.0, 2.6

HTML Form Entry Extensions for OpenMRS 1.9 - 1.8, 1.6.1

Reference Demo Data (optional) - 1.4.2, 1.4.1

Data Exchange - 1.3.2, 1.3.1

Allergy API - 1.5, 1.4

Allergy UI - 1.6, 1.5

Form Entry App - 1.3, 1.2

Chart Search Module - 1.6, 1.5

Name Phonetics - 1.6, 1.5

@jdegraft by the way, it is supposed to be on platform 1.11.6

@jdegraft how is this going? Do you think you will be able to release by this week? Or should we help you? We are not putting you on pressure because we fully understand your other commitments. We just do not want to go beyond this week before this release is done! :slight_smile:

@dkayiwa, I have done some testing. We should go ahead and release the software.

@darius wanted the latest modules.

I will release the reference application modules this evening and submit a pull request for the distro pom with the appropriate module versions.

I can work on the documentation after the software is released, should take about a week.