Hi folks,
I’ve been thinking about @janflowers request to have more concentrated community attention around making implementers’ lives easier when it comes to upgrades. And actually we hear this from implementers all the time: That upgrades are big, hard, and scary. A lot of work.
The thing is, it seems like “upgrade” can mean a lot of different things. Here’s the summary of where my thoughts are at:
Type
Overseen by
Migrating from other system to OpenMRS
Implementers (b/c many custom, bespoke needs)
Upgrading from Platform 1.x → 1.x+.1
A team responsible for platform releases & oversight
Upgrading from Platform 1.x → 2.x
A team responsible for platform releases & oversight
Upgrading from Platform 2.x → 2.x+.1
A team responsible for platform releases & oversight
Upgrading from RefApp 2.x → 2.x+.1
?
Upgrading from RefApp 2.x → 3.x
MFE Squad + A team responsible for platform releases & oversight
Migrating to use additional package (e.g. OHRI HIV package)
TBD (likely MFE Squad + OHRI-funded resources which I think have yet to be identified)
Since this is a topic for next week’s Strategy & Operations call I thought I’d share early.
“What do we mean by upgrades?” is a fantastic question!
So before we start talking about who oversees what type of upgrade, it would be helpful to unpack what is involved in an upgrade. I’m thinking about things like:
Individual modules - community or custom?
Migrating data
Quality assurance
Packaging and deploying
Updating technical documentation
Updating user materials
What use cases are we talking about here? Here are a few that come to mind:
“I want to upgrade our platform libraries.”
“I want to upgrade my implementation to the most recent version of the OpenMRS Platform”
“I want to upgrade my implementation’s XX modules”
Just a small note on this: we should probably not call the upgrade to the 3.0 UI a “platform” upgrade. MFE squad is really building a new UI, but one which is (AFAIK) compatible with platform 2.x (openmrs-spa is running on RefApp 2.9 / Platform 2.1.4 with some updated modules). If and when we get to a 3.0 version of the platform, of course, we’ll want to keep that usable with the 3.0 UI.
Also I 100% agree with @jennifer that it would be good to be sure we carefully unpack what an “upgrade” is as this does mean different things to different people and I think it’s hard to make an “upgrade” as being any single team’s responsibility; there are too many moving parts.
For instance, it would be nice if there were a “platform team” that had as part of their scope ensuring that there are clear migration paths between different versions of OpenMRS, e.g., how do I adopt the new Condition model in 2.2 while maintaining my existing data? A good step towards this would be to publish a upgrade guide along with each release, as well as any known breaking changes and recommended ways to fix them. E.g., @dkayiwa did a fantastic job of updating all of the RefApp modules to support platform 2.4, but it would be nice to have the kind of changes necessary laid out clearly for implementers so they don’t have to do trawling through the Git history to see how this was done.
But even that wouldn’t necessarily solve all upgrade concerns, e.g., how do I get my customised forms from 1.0 to show-up in the 2.0 or 3.0 UI?—at least the 2.0 version of this question has shown up on Talk quite a bit lately. A better example might be: how do I get my custom module for 1.x working on 2.x? On 3.x?
One exercise that might be helpful is to see if we can get some input on pain-points implementers find when “upgrading” (whatever this might mean). That might help clarify both what “upgrading” means and where we should try to direct resources.