Releasing O3 Ref App 3.0.0-alpha

Software Reference App
, ,
16

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] Release of Distro Ref App 3.0.0 (alpha) - 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 :slight_smile: 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.

1 Like
17

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.

3 Likes
18

KeyCloak is related only with Dictionary manager so it won’t affect OCL Module.

1 Like
19

Thanks for the fixes on the Cohort module @ibacher. Version 3.2.0 is now released.

20

@mseaton could you confirm that you’re ok with us releasing Reporting REST 1.14.0?

21

Updated as of Nov 1st:

Already released

Ready to be released

  • Attachments 3.0.0
  • Iniz 2.4.0
  • Queue 1.0.0-alpha
  • Reference Demo Data 2.0.0

Not ready / questions pending

  • Core 2.5.8 - Ian Bacher + Daniel Kayiwa to confirm.
  • Bahmni Appointments 1.6.0 - we keep monitoring discussions on Bahmni Slack here.
  • OCL 2.0.0 - answers are not associated with their concept in the OCL export file, further details to be provided by Nathan Ruhanga on Talk.
  • Reporting REST 1.14.0 - confirmation asked on Talk here.
1 Like
22

@mksd / @ruhanga - releasing reportingrest 1.14.0 is OK I guess if you really want to, but there is nothing really to release.

If you look at the github commit history here: Commits · openmrs/openmrs-module-reportingrest · GitHub

You’ll see that there is nothing committed since 1.13.0 that will have any meaningful impact on your current distribution. I’d just stick with 1.13.0.

Mike

1 Like
23

Makes sense indeed to use 1.13.0 for the 3.0.0-alpha release. Thanks for the clarifying this @mseaton.

24

Update as of Nov 2nd:

Already released

Ready to be released

  • Core 2.5.8 (see here)
  • Iniz 2.4.0

Not ready / questions pending

25

The release of the OCL module should not be blocked following the post I’ve created here @mksd.

26

Update as of Nov 3rd:

Already released

Ready to be released

  • Core 2.5.8 (see here)
  • Iniz 2.4.0 - let’s release this with the next iteration at 2.4.1-SNAPSHOT to fix the Validator.

Not ready / questions pending

  • Bahmni Appointments 1.6.0 - we keep monitoring discussions on Bahmni Slack here.
27

Update as of Nov 9th:

Already released

Ready to be released

  • Core 2.5.8 (see here)
  • Bahmni Appointments 1.6.0-alpha - as a temporary measure, we will deploy it on Mekom’s Nexus, cc @angshuonline.

Not ready / questions pending

  • Iniz 2.4.1 will fix the Validator and will be used in the beta or full release.
1 Like
28

Update as of Nov 11th:

Already released

Ready to be released

(N/A)

Not ready / questions pending

  • Bahmni Appointments 1.6.0-alpha - blocked by BAH-2569
29

Update as of Nov 16th:

All Maven artifacts have been released :tada: It is now up to @ruhanga to up the versions to those releases in the Ref App 3.x distro:

30

PR here actually → RA-1994: Upping dependencies to released versions. by Ruhanga · Pull Request #658 · openmrs/openmrs-distro-referenceapplication · GitHub

31

@ibacher from a Maven perspective we would be good to release a first alpha. However we need to understand how to ensure that this 3.0.0-alpha also encompasses the same fixed snapshot of the frontend. Could @ruhanga and yourself liaise to make this happen and establish that process?

This is important because we know that another 3.0.0-alpha.2 will follow suit shortly, presumably with the same backend and with an updated frontend.

32

I actually don’t think there’s anything that needs to be done here as long as we’re clear that the 3.x RefApp currently just releases Docker images and not any other packaging or artefacts for now (we’ve still got a long way to go before we can replace the 2.x RefApp with a 3.x version). That’s because our Docker images all embed the runtime files, so we already have a fixed set of frontend modules.

33

@ibacher so when we create a Git tag 3.0.0 when releasing, there is no need for all these guys to be set to something fixed?

In other words, is it ok, when looking at a released tag in Git, to see next as a version for each ESM?

34

Yes, but only because we aren’t publishing something (like with the 2.x RefApp) that allows you to recreate the build. The Docker image for the frontend will be fixed, resolved versions (albeit currently with pre-release numbers).

35

Even if we’re not publishing those through the build, if only for setting things straight as per the release tag, I think I would feel more comfortable if the actual versions are set there.

This would be just for the release tag, we would bump them up to next right after for the commit setting the next development iteration.