# Module compliance with Platform 3.X **URL:** \ **Category:** Platform\ **Tags:** module, community-modules\ **Created:** [October 1, 2025, 7:40am UTC](https://talk.openmrs.org/t/module-compliance-with-platform-3-x/47158 "2025-10-01T07:40:37Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [October 1, 2025, 7:40am UTC](https://talk.openmrs.org/t/module-compliance-with-platform-3-x/47158/1 "2025-10-01T07:40:37Z")
Dear all following on-going discussions on [Call for Suggestions: OpenMRS Platform 3.0.0](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/33) , a [suggestion was made to create 3.0.0-snapshot branches for modules](https://talk.openmrs.org/t/top-product-priorities-for-next-1-month-community-discussion/47125/3) 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](https://openmrs.atlassian.net/browse/PLAT-83) for quick tracking of the progress @dkayiwa / @burke / @ibacher / @ruhanga /@wikumc / @grace[@dev5](https://talk.openmrs.org/groups/dev5) [@dev4](https://talk.openmrs.org/groups/dev4) [@dev3](https://talk.openmrs.org/groups/dev3)[@dev2](https://talk.openmrs.org/groups/dev2) We can discuss more at the weekly platform calls Began with this list from refapp 3.X ```auto 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 ``` ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [October 1, 2025, 10:50am UTC](https://talk.openmrs.org/t/module-compliance-with-platform-3-x/47158/2 "2025-10-01T10:50:28Z")
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. ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [October 1, 2025, 10:51am UTC](https://talk.openmrs.org/t/module-compliance-with-platform-3-x/47158/3 "2025-10-01T10:51:05Z")
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. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [October 1, 2025, 11:38am UTC](https://talk.openmrs.org/t/module-compliance-with-platform-3-x/47158/4 "2025-10-01T11:38:37Z")
> [@ibacher](#): > > 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). Good observation had completely under-looked the fact the we have things way above 3.x ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [October 1, 2025, 11:44am UTC](https://talk.openmrs.org/t/module-compliance-with-platform-3-x/47158/5 "2025-10-01T11:44:24Z")
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.