Request To confirm Modules For Reference Application 2.5

This is to kindly Request All module owners whose modules require to be upgraded to confirm the time on which their modules will be ready for release in order to help us include them in the Reference Application 2.5.

The following modules have not yet been confirmed Provider Management @mogoodrich , Serialization.xstream by @mseaton , reporting by @mseaton , metadasharing by @raff , metadatamapping by @raff, htmlformentryui by @darius and @mogoodrich, idgen @dkayiwa and @mseaton, htmlformentry @darius and @mogoodrich, formentryapp @darius , @raff and @cintiadr, uiframework @dkayiwa, appui @darius and @mogoodrich, uicommons by @darius, event @dkayiwa and @raff, allergyui @dkayiwa, registrationapp @darius, @mogoodrich, referencemetadata, appointmentscheduling, appointmentschedulingui, legacyui.

Also check on https://wiki.openmrs.org/display/RES/Reference+Application+2.5+Release+Issue+Tracking to confirm whether the module version exists on modulus so that if it doesn’t you can please upload it.

The release for Reference Application 2.5 still remains 30th september!
1 Like

Thanks @taremwatadeo for keeping us updated on this. Am responsible for most of these because of the recent commits to make them platform 2.0 compliant. The delays have been caused by some followup commits due to issues reported by various people trying out these modules in their distributions. Am doing a final round of testing and planned to have all of them released by Monday! So shout out to me if this does not happen! :smile:

I’ll take a look, thanks @taremwatadeo

1 Like

@taremwatadeo @dkayiwa

As for the modules I am involved with, I see the following needing releasing:

idgen providermanagement htmlformentry htmlformentryui appui registrationapp appointmentscheduling appointmentschedulingui

I can start working on releasing some of these, but @dkayiwa let me know I should wait on any of them because of the 2.0 changes/fixes.

Thanks, Mark

@mogoodrich just go ahead and do the needful. :smile:

Will do, thanks!

We are trying to switch to proper semantic version (ie always including three numbers, MAJOR.MINOR.PATCH) going forward, correct?

@dkayiwa I just released the following modules. Hopefully I will be able to do a few more tomorrow.

htmlformentry idgen appointmentscheduling providermanagement

That was awesomely fast!!! Thanks a lot @mogoodrich :smile:

First of all thanks everyone for this important upcoming release that will run on Platform 2.0. This is a tremendous change and we are happy to see that the Ref App, through its 2.5 release, is already Platform 2.0 compatible!

I would like to use this thread to bring one point to the attention of every releaser. Would it be possible to pay attention, when releasing your modules, to ensuring that no SNAPSHOT dependencies are left behind in their POMs? I suspect that this could mean that no module may depend on the distro. Because since the distro is presumably released after its modules, I would assume that when a given module is being released it may still depend on the about-to-be-released (and hence still SNAPSHOT) distro. Does that make sense?

Lingering SNAPSHOT dependencies have caused all sort of troubles in the past and up to now, and developers don’t want to fork a module just for editing one line in a POM (with all the CI changes induced by forking a module…)

Thanks!

@mksd very good suggestion. Though most of them are already released (~80%). Do you think we should release them again?

@dkayiwa I think @mksd has a valid point - if all the modules are based on release versions that means that the Ref App release is self contained, and can be built in a repeatable manner

It would be neat it someone could write a little script that determines (based on the refapp 2.5 pom) if any of the modules to be included have snapshot dependencies.

-Darius (by phone)

If that is still an option, I would say yes. And then this should become the new normal when releasing a module: no more SNAPSHOT dependencies.

So I guess releasers should start by ridding their modules of the dependency on the distro. Is everybody ok with this?

OK. So it looks like the consensus is to release all modules again while not depending on the distro snapshot. Does anyone have a workaround for not having to manually put each dependency version in each module?

I just released htmlformentryui, and am in the process of releasing appointmentschedulingui now. I took myself off the reference application module.

I think that takes care of all of the ones with my name, except for appui and registrationapp, as what we are doing with then depends on the distro snapshot discussion.

If we want to get rid of the circular dependency on the distro snapshot (+1 to that, it has been causing lots of problems, just a matter of coming up with an acceptable alternative) one thing we could do is to add all the dependencies back manually into the modules that depend on the distro, but then for these modules set up a step in their build plans to use the maven versions plugin to upgrade there dependencies to the latest released version of each module. This is what we use in our PIH build, and it seems to work pretty well. If people are interested, I can set up one of the modules that way as an example.

Take care, Mark

Thank you so much. That will push us closer to releasing

1 Like

@mogoodrich am interested in that. Can you set up one module as an example?

Sure, @dkayiwa… anyone have recommendations of a good module to start with?

@mogoodrich how about the coreapps module?