Today in the Platform Team call @burke & @dkayiwa raised a good point; we should do a RefApp release in 2022.
Reason to do this at all: Ensure Modules that need releases are indeed released, and it’s clear what the latest stable versions are.
Watching @mksd’s latest posts on getting the main modules updated for RefApp 3.x (Releasing O3 Ref App 3.0.0-alpha) was a good reminder that a number of foundational modules needed some version # / update TLC.
Proposal for RefApp 2.13
Scope: Focus on (1) Module Updates and (2) checking for any major, critical blockers (e.g. system won’t start).
Testing Plan:
Release Manager to recruit some support from QA Support Team members to manually smoke-test 2.13
But: Those testing should focus on major blockers only - not small issues found. I.e. just check that things load and major actions can be done.
For everthing else, we’ll rely on Automated Tests that have already been set up for 2.x → makes it so we don’t need full manual testing like we used to for more detailed workflows
Next steps:
We need a Release Manager to review any Module version #s or releases needed, set up a Release page like this to capture that version change info, to organize the manual sanity tests with the QA Support Team (or by themselves is fine too as it should be quick), and to do the release blog posts. Anyone interested?
Just in case it doesn’t harm when two volunteers work together through the releasing process, then would be happy to work with @jwnasambu towards the release of RefApp 2.13
updated the modules to there current release version except Atlas module which I believe is a release candidate.
I checked the tickets on jira that are related to this release and I can confirm they are all fixed. (The latest was approved by @ibacher before closing it).
Could there be a reason why you have used platform 2.5.7 instead of 2.5.8?
I also see changes after some versions of modules listed in your release notes. Wouldn’t it be better to first release those modules and then include versions that have the latest changes?
I followed this link Tags · openmrs/openmrs-distro-platform · GitHub and it still reflects platform 2.5.7 though I have confirmed version 2.5.8 was released 5days ago. I think that is where I confused myself.
Great work @jwnasambu! Both those Wiki pages look good - thank you for doing this so expeditiously and efficiently. I just added the same notes as above w.r.t. scope of this release.
Wow - seeing that only 3 modules’ versions were “maintained” is such a good eye-opener about the need to do this release and keep things fresh
For release date - I’m thinking anytime in Nov or December; just whenever we can that is before the end of 2022. How does that sound to you Juliet?
[quote=“grace, post:11, topic:37824”]
For release date - I’m thinking anytime in Nov or December; just whenever we can that is before the end of 2022
You are right.
Cloning into 'target/distribution'... error: pathspec 'master' did not match any file(s) known to git Failing task since return code of [/bin/bash release-scripts/distro-update.sh -r 2.14.0 -d 2.15.0-SNAPSHOT -p providermanagementVersion -s git@github.com:openmrs/openmrs-distro-referenceapplication.git -b master -n false] was 1 while expected 0
Kindly how can I fix this error? besides the version tag is updated even when the release failed on the way. Do I need to delete the tag and begin the release a fresh?
I’m having a different error when I try to release the App Framework module. When I run the standard build on CI, it builds successfully, and all the tests pass, but when I run the release job, the test fail, with this error being reflected
ERROR - TestContextManager.prepareTestInstance(324) |2022-11-21 18:17:31,339| Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@43462cef] to prepare test instance [org.openmrs.module.appframework.service.AppFrameworkServiceTest@64287ec0]
After running the plan do I need to release again or that is all? Besides, am facing the same problem with another module that I have tried to release. I desire to modify the bamboo job with JAVA_HOME=${bamboo.capability.system.jdk.JDK 8} but am a bit stack with the path to follow in order to achieve it. Kindly do I need permission to do it?
To be honest I didn’t re-run the release again because I already had a tag of a new release created
e.g. Appointment Scheduling/tags. My assumption is when I release again it will create another release of 1.18.0 which I believe is wrong. The only would be solution if am to release again(in my own thinking) am to delete the tag on the repository then release afresh
t[ERROR] mvn release:prepare failed. Attempting to do a release rollback.
[ERROR] mvn release:prepare failed, scroll up the logs to see the error. release:rollback was attempted. Delete the tag from the repository (if it exists), check if the SCM tag is a ssh and not http and try again.
when I try to release some modules e.g. Metadata Mapping Module. Kindly how can I go about it please!
