We are in the Process of releasing Reference Application 2.7.0 based on OpenMRS Platform 2.0.5 .
We therefore urge all module owners / maintainers which are already resident in Refapp 2.6 to release new versions of their modules (or approve usage of the existing version/s) within the next few days so we can strike the targeted release schedule.
Please Take Note :
Below is a List of Modules and their corresponding current / SNAPSHOT versions we expect to ship with RefApp 2.7 .We recommend that you give us feed back concerning their version validity as soon as possible, for auditing purposes , so that we may finalise before 27th October 2017.
@tendomart, I’m a little confused about the Reference App Release Tracking page… I think most cases the “Version /Notes/Tracking” column show shows the most recently released version of a module. For each module, I assume the correct process would be for one of the module owners to 1) confirm if we want to use that version or if we should do a new release, and 2) if a new release is needed, somewhat should go ahead and do it.
To facilitate this can we add a new column to named “Ready?” or something like that, to reflect that a module owner has signed off on the module version listed in the “Version” column?
In general, I think we should strive to release as many modules as possible, otherwise the changes may not get into the latest release.
As an example, I added the Html Form Entry to the list (not sure why it was missing). I confirmed that the latest release (3.4.0) is good to use (there have been no additional commits since the release) so I flagged as “Ready” in a new column I added to the spreadsheet.
I also marked the two modules that @mksd mentioned above as “Ready”. So the goal would be for all module owners to review their modules and get every one marked “Ready”.
Does this work for you @tendomart? I will continue to review the rest of the modules flagged with my name over the next couple days.
@mogoodrich Thank you very much for the reviews , observations ,suggestions and corrections Iam working around the clock to make sure that i rectify the inconsistencies and or add new features.You will soon see the changes
@mogoodrich Thanks alot for the edit. sorry i had accidentally deleted htmlformentry from the list during editing , but it’s resident on my original list of the openmrs-distro-referenceapplication file
Okay, so I went through the bulk of the modules I was an owner or co-owner of and did a new release as necessary, or just noted that the most recent release should be used. I marked all the ones I reviewed as “Ready”.
There were a few I did not yet release:
registrationapp & coreapps - I believe we should do a release of these modules, but I wanted to check with @ssmusoke@craigappl… do you guys think they are ready to go from your end? Do you have any outstanding changes you were planning on pushing up before the release? There may be some new features that we at PIH added (like biometrics) may not be 100% final, but I don’t think this is a blocker because it’s not functionality that appears in the Ref App by default. If we all agree, I can go ahead and release them.
idgen - I would check with the team working on adding REST support for IDGEN and see if we want to use the latest version of IDGEN or if we should just stick with the last released version (4.4.1, I believe). It looks like there were no new additions since the last release besides the changes to support REST.
I can’t get the registration app and registration core code turned around quickly enough to make this release. I need to write up the feature set, create the tickets, rebase the commits and create a PR before the code is ready to be added.
Great! I should be able to go ahead and do a release of Core Apps and Registration App later today or tomorrow if someone else doesn’t get to it first.
Should we start updating the Ref App distro pom to point to all these new releases so that they go out to the QA server for testing?
Thanks what I thought @dkayiwa, but looking at the Ref App QA server, it didn’t seem to have the proper versions of the modules running. I will try to take a closer look.
Ah, I see my mistake @dkayiwa… I just glanced at the versions of modules running on qa-refapp and saw many more SNAPSHOTS than I expected to. But those are the latest snapshots… so when I do a new release and then the new SNAPSHOT version is created, it jumped immediately to the new SNAPSHOT.
This is is what we generally want, I believe, but I don’t know if during the testing phase just prior to a release we want to lock it down to the actual released versions we plan to include in the release?
When releasing a module 'If this module is part of the reference application, other option you might want to override is the global variable 'preparing.refapp.distro.release.
When it’s true, the refapp distro will be updated with the released version; when it’s false, with the next snapshot.
Thanks @cintiadr, that’s great! Sorry I didn’t actually read the instructions first… I have one or two more modules to release, I will try to do it with those.
Since I didn’t actually do that this time, shall I go ahead and manually set the versions in the pom back to the most recently released versions, the ones we want in Ref App 2.7? @ssmusoke@tendomart
I have one or two more modules to release, I will try to do it with those.