Module compliance with Platform 3.X

Software Platform
,
1

Dear all following on-going discussions on Call for Suggestions: OpenMRS Platform 3.0.0 , a suggestion was made to create 3.0.0-snapshot branches for modules as we travel together towards an OpenMRS Platform 3.X

we are glad to let you know that we are beginning a parallel task of making modules compliant with platform 3.X and that means beginning with creating 3.0.0-snapshot branches where work can be propagated.

Your inputs are highly welcome especially on who should make it to the list and who should not be a priority as per now

Created an Epic at Jira for quick tracking of the progress

@dkayiwa / @burke / @ibacher / @ruhanga /@wikumc / @grace @dev5 @dev4 @dev3 @dev2

We can discuss more at the weekly platform calls

Began with this list from refapp 3.X

  omod.initializer, 
  omod.fhir2,
  omod.webservices.rest,
  omod.idgen,
  omod.legacyui,
  omod.addresshierarchy,
  omod.metadatamapping,
  omod.openconceptlab,
  omod.referencedemodata,
  omod.attachments,
  omod.queue,
  omod.appointments,
  omod.appointments,
  omod.teleconsultation,
  omod.teleconsultation,
  omod.cohort,
  omod.reporting,
  omod.reportingrest,
  omod.calculation,
  omod.htmlwidgets,
  omod.serialization.xstream,
  omod.ordertemplates,
  omod.patientflags,
  omod.o3forms,
  omod.authentication,
  omod.emrapi,
  omod.event,
  omod.bedmanagement,
  omod.stockmanagement,
  omod.billing,
  content.referenceapplication,
  content.referenceapplication-demo
1 Like
2

Several points here:

  1. While it makes sense to create new branches (eventually) in modules, they should not be called 3.x, but whatever the next major version is. Universally versioning things 3.x is a bad idea. (E.g., HFE is already on 6.1.0-SNAPSHOT, so the version compatible with 3.x is at least 7.0.0-SNAPSHOT).
  2. While it’s probably a good idea to do that eventually, I think we’re being a bit premature thinking about that now. We first need to start making the breaking changes in Core so that we know where we need to change things in modules. Creating branches now means we double the maintenance work on modules as everything will need to be either done on the “new“ 3.x branch or backported there. Basically, we should allow modules to evolve while we work on the changes to core and then work on making the compatible with the new version of core once the features are stabilised.

Basically, let’s get on ducks in a row on implementing core 3.x and then start in on modules once we have a clearer shape for that.

3

Module support for platform 3.0 is going to be on master branches of modules. It is the backwards campatible branches that are created for each module. Branch name depending on current module version. For instance, 1.7.0-SNAPSHOT results into 1.7.x branch.

3 Likes
4

Good observation had completely under-looked the fact the we have things way above 3.x

5

It’s also a lesson from the O3 frontend where we started almost everything at version 3.x and, consequently, when we released RefApp 3.0.0, we had 0 modules on version 3.x (we released versions like 5.6.0, 8.0.0, and 7.0.0 because of the changes we had to make overtime).

Anyways, key point is that we’re not yet at the point to think about module branching. When we get there, as Daniel said, we’ll do the 3.0.0 compatibility in the main branch and create a branch for pre-3.x compatibility. The first thing we need to do is dig into making 3.0.0 core work.

2 Likes