@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:
Reference Demo Data
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.
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.