I’ve just created a setup for releasing a platform as a bundle of war and modules: webservices.rest, fhir, owa… It will be used by SDK as well to setup servers…
My after thought is that probably instead of using a separate github repo with separate release plans, I could have just added a platform maven submodule to the openmrs-core repo.
The question is if at any point in the future we will want to release API separately from platform? If we do then it makes sense to keep the 2 repos separate, but otherwise it will be simpler to just keep the platform info in the openmrs-core repo.
Raff help me understand here. On this line I see the platform is packaged as jar even though your post seems to give the impression that the platform is supposed to be packaged as a war. Am I missing something?
To answer your question I think ideally it is cleaner to keep the api & platform separate. However the reality is bit different because the platform release really depends on the core api releases. In theory one may argue that a new platform may be released following a new rest/fhir module release, that is without changes in the core but this is rarely the case. Practically if a new rest/fhir module version is released one may simply update the existing platform by installing the new version.
So IMO I don’t think it is necessary to keep this in a separate repo.
The intention is for openmrs-core and platform releases to be synchronized, so from that perspective I’m in favor of having it be a single repo and plan.
(I don’t know if technically we need to release openmrs-core first for some reason, e.g. because we might need to build the RESTWS or FHIR modules against the just-released openmrs-core before releasing platform.)
I assume we still plan to do releases of individual core modules like webservices.rest without releasing the entire platform and/or core, and that making this change won’t prevent that?
While I agree with others that their could be Platform releases without any change to openmrs-core (i.e., just changes in bundled modules), I don’t think that alone justifies having a separate repo.
Definitely.
My understanding of the purpose of the platform-distro repository was to coordinate the release & versioning of the components (core + modules) that go into the platform. From my experience, we never got it quite right, since the release process seems to have cyclic dependencies that confusing devs and release managers. I too am all for consolidation, but would really love to take this opportunity to clarify and simplify the release process.
We should avoid releasing anything with SNAPSHOT dependencies.
There should be a config/pom/whatever that defines the version of each module for a Platform release. This should be created at the beginning of release planning for the Platform and can point to snapshots for modules are under development, but the Platform should never be released with any snapshot dependencies.
When we have situations where both a module’s next release and the Platform’s next release depend on each other, then we should have a well-defined (preferably automated) process for explicitly handling those cases predictably & cleanly (e.g., a single process that releases and removes snapshot dependencies for both sides in a single step … or a mechanism that allows maven to substitute a snapshot version of the API in place of an yet-to-be-released official API release named in the module’s POM when building a module in preparation for a new Platform release).
If those problems have already been solved, please educate me. If not, let’s solve them as we consolidate.
@willa, the purpose of publishing a jar is to use it in SDK or any other tool, which can read openmrs-distro.properties stored inside the jar to get declared versions of core and modules.
In addition to that jar we could publish to maven a war with bundled modules, but it’s not yet configured that way.
@darius, it is a fair point that we might need to release RESTWS with e.g. openmrs-api 2.1.0 support before releasing the 2.1.0 platform… I haven’t thought about that.
It means we’ll have to release openmrs-api and platform in separate steps as I configured it now.
I’ll add a check to prevent releasing platform with SNAPSHOT dependencies. When someone tries to do that, maven will print out a list of dependencies, which need to be released first. One will have to release those dependencies manually.
I’ll tweak the config and update platform release instructions…
So what is the purpose of continuing to openmrs-distro-platform as a separate project rather than a sub-module of openmrs-core?
During the release process this is one of the more painful aspects of the process, having to edit multiple projects like this one, then the standalone.
@ssmusoke, the purpose is to be able to release openmrs-api so that modules can depend on it, before releasing the actual platform with that modules coming as bundled.
We could look into building the standalone together with the platform so that we do not add more steps to the release process… Simplifying the release process is something I’d love us to do in the coming year
@raff, is the Platform Distro repo what we should be using to do our platform releases now? Are there instructions for this?
@maurya, can you make sure (in a PM sense) that we prioritize streamlining the platform release process (especially for maintenance releases, which should be almost automatic), and update our documentation to reflect this?
