@dkayiwa@grace@ibacher as we are heading into an Ozone 1.0.0-alpha release, we will need an O3 Ref App 3.0.0-alpha release.
First, here are the good old backend Maven artifacts that need attention:
Artefact
Snapshot version
Core
2.5.7-SNAPSHOT
Iniz
2.4.0-SNAPSHOT
REST WS
2.37.0-SNAPSHOT
OCL
2.0.0-SNAPSHOT
Attachments
3.0.0-SNAPSHOT
Reference Demo Data
2.0.0-SNAPSHOT
Queue
1.0.0-SNAPSHOT
(Bahmni) Appointments
1.6.0-SNAPSHOT
Cohort
3.2.0-SNAPSHOT
Reporting
1.25.0-SNAPSHOT
Reporting REST
1.14.0-SNAPSHOT
Are we good to release all this? If some projects are really not ready yet, can we do an alpha release and resume working on the snapshot just after that (or move to the next patch version after that, in anticipation that patches will be needed)?
@grace any frontend known horrors that would prevent an alpha release now? What about the drug ordering calculation bug?
@ibacher I suppose that once all the above is released, we can actually proceed to release an alpha of the distro?
@grace what about release notes, any thoughts there?
@ibacher what is the process for releasing the frontend?
@dkayiwa can we make 3.x become main and master become 2.x?
Not yet. There’s a bug in the current implementation that should be fixed before we do a release (a property marked as not-null in the Hibernate config is nullable in the database schema, which causes the feature to break).
This is pretty stable at this point, so yes.
@mseaton I can’t remember if we addressed all the FHIR stuff yet? If so, I’ll do a release of FHIR2 so we can update Iniz to rely on that version.
It would probably be best if we could fix and backport this issue first (PR almost ready).
Another thing that should probably be fixed before we do an alpha of Ozone (or the RefApp, really) is this issue (slightly longer explanation on Slack, but in essence the current locale switcher does not actually switch the locale on the backend).
It’s a mostly-frontend issue. I did have one backend-related question for that: The issue arose because in 2.x, updating the users default locale also updated the current session locale. However, the logic to do this was in the page controller, and so not part of the standard API. We could add that logic in, either in the REST API (which won’t affect the Legacy UI) or as part of core (which will change the functionality of the Legacy UI as well). It wasn’t clear to me if either or both of those was the “correct” thing to do (in either case, the frontend should probably just be responsible for updating the session locale and let the backend persist that as the user’s default locale if that’s desired).
The existing tickets are linked in my post above (TRUNK-6141 and O3-1565). The Cohort module thing hasn’t been ticketed yet, but I’ll do so shortly.
@suruchi are you aware of anything that should cause concern about releasing the OCL Module version update? Would the new KeyCloak blocker be an issue?
@mksd no one has stepped forward to fix this do you have a dev resource who I could work with?
Otherwise, no, no other known horrors but I’ll do detailed testing again this Thursday after calls end just to be really sure.
FYI @mksd we are following your precedent and linking any issues related to the O3.0.0-alpha release (eg blockers, high priorities) to [RA-1994] - OpenMRS Issues
Done and will continue to follow up. Discussion happened about this today w/ me/Vineet/Romain.
@corneliouzbett assuming your fixes are on the Patient Queuing module, that makes sense to me If you get blocked feel free to create the ticket in the RA or O3 project and we can always move the ticket later if needed. Let’s not let Jira itself be a blocker.
TRUNK-6141 and the Cohort module issue should be fixed now. I’ve also kicked off a release for FHIR2 1.6.0, which is a pre-requisite for Iniz. This couldn’t just be a patch update as I’d have to unwind the MedicationDispense stuff to do that. For now, though, I’m considering the MedicationDispense support “experimental”, i.e., it probably works, but isn’t ready for production use.
do you have a dev resource who I could work with?