If we do things like I said above, for example:
openmrs-core 2.1 (release March 2017, no guarantee of support beyond release of 2.2)
…then I would be uncomfortable basing RA releases on this. So this would mean we’d need to promise more support than I was thinking, right?
Also, in that model I’ve said we’re only releasing openmrs-core, not a full platform release, so we’d end up with RA releases without a true corresponding platform release.
These would seem like problem, right?
Well looking at the RA release schedule we would release RA based on LTS at least once a year and thrice a year based on non-LTS so an implementer would have a choice based on a planned upgrade scheduled.
Anyway, to keep things simple let’s just say RA is always based on LTS. We can revisit that, if we actually want to use some feature in RA from a non-LTS release. It’s not the case right now and there are other options to go around it, which can be considered e.g. enabling a feature optionally.
Is it possible to simplify the release process for Platform? Something like this for a non-LTS version of the Platform:
Do we anticipate that these non-TLS “core” releases might not actually work for the platform (e.g., OpenMRS Core 2.1 comes out and not all the platform modules will run against it, so a Platform release isn’t possible until the module(s) have been refactored to work with core changes)?
If we aren’t packaging & release core with platform modules, then I agree we shouldn’t label it as a “Platform” release. We’ll need to update the wiki to give some explanation of what this “OpenMRS Core” thing is. But, I’d rather make it easier to package up & release a non-LTS version of the Platform than finding a way to avoid releasing the platform. Automating packaging & release of non-TLS versions of the Platform would not only make things easier to understand (avoid adding a new “Core” beast to our road map + skipping version numbers in the Platform), but also improve LTS releases (which would benefit from the automation).
In this specific case we are adding obs.status and obs.interpretation, but since Bahmni doesn’t use the FHIR module we will not make changes to the FHIR module to support that.
(We do need the REST module to support these new changes, so we will take care of that, and release a new REST module version.)
In other words, doing a core-only release is significantly less work for the devs who want to do it, versus a full platform release, even if we script the platform release process to make it easier. (We should do that anyway.)
FYI I have released openmrs-core 2.1.0.
I updated our OpenMRS Release Policy wiki page to mention the idea of non-LTS dev-targeted releases, but what I wrote was pretty anemic (like the rest of that page).
In the next few days I intend to release the REST webservices module, and also write a more verbose wiki page about what non-LTS means.