Releasing O3 Ref App 3.0.0-alpha

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

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

@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

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

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

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

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.

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

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

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:

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

@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.

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.

@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?

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).

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.

@ibacher I don’t like (at all) the idea that the distro isn’t reliably producing and packaging all the artefacts that it is made of. This sounds like an anti-pattern to me, or at the very least a weaker pattern. And I don’t like the idea that the distro would be just the backend distro - we have no use of this within Ozone.

Perhaps there are compelling ways to have diverted from the original pattern of a fully reliable and rebuildable distro, in which case I am all ears :ear: But if those were shortcuts to get quicker to a place solely focused on producing Docker images for the frontend, then we need now to finish this up and be in a world that achieves both goals:

  1. Software distros that can be reliably built.
  2. Docker images made available when they should (like it is now).

Can we discuss this over the next TAC call?

@burke @mseaton, thoughts?

I’d definitely be interested in learning more about where we currently are with this. I’m not sure I’m up to speed. @mksd - it sounds like you are saying that we are only producing a Docker image now for the backend, and outside of that Docker image there is no artifact that represents the backend (eg. a zip of the war + modules), the frontend, or the entire distribution (backend, config, frontend)? I would tend to agree that a Docker image is secondary to producing the actual distribution artifacts, which may or may not be run in Docker.

So my understanding is that for the backend + (backend) config, all is fine, you will get all this out of the Maven build of the distro. However the frontend artefacts will be missing, and I would like to add them back (it used to be the case months back).

The frontend is only produced as a Docker image.

But again @ibacher / @mksrom could you confirm?

So, first, I fully agree that where we are is not an ideal situation. We moved away from using the SDK for everything because it’s proven hard to keep things working stably with the SDK. Some parts of the frontend build needed to be wrangled to be able to consistently reproduce builds (this still isn’t completely done, but the most pressing things are fixed). A second aspect of this is just that the SDK-based built was, for various reasons, quite wasteful of disk space, which needed to be fixed to have a pipeline that regularly worked. There are some parts of the SDK that need to be revised a bit to generate an output that’s more suitable for the images we’re now using and the SDK should be changed to actually use those same outputs. Also, right now, the distro is currently also hosting the metadata, which is not an ideal setup. Ideally, we’d actually have at least two metadata repos, one focused on the metadata to make things work and one focused on the additional metadata we need for demo environments. Those repos / maven modules / etc. should be setup to produce some kind of artefact that the SDK is setup to consume (this probably means integrating some kind of metadata namespace that will download a zip of metadata and unpack it into the appropriate location in the distro). Finally, I think we need to look into the output produced by the SDK and change it to match the conventions implied both by our current Docker images and the 3.x RefApp build.

With those steps done, it should be possible to return the RefApp build to using the SDK to actually produce the build, which gets us several steps closer to where we want to be. The last bit of clean-up is ensuring that the setup commands actually work with this and have some “specialised” logic to handle installing module-spa if a 3.x frontend is included.