We want to bring some changes on coreapps. The latest coreapps SNAPSHOT is 1.11.2 which is NOT compatible with 2.3.1 modules. However, our OpenHMIS modules still work with 2.3.1 modules and we would love the new feature to work with 2.3.1 modules.
Question: Is it possible to work off coreapps release tag 1.7 and later release 2.3.2 modules? This would be particularly helpful to allow backward compatibility with modules still using 2.3.1.
I hope it’s clear.
Thanks, Andrew
+1 We also would like this, there are quite a few changes that we have made to Core Apps (rather round v 1.8), and we never had the time to make PR for those. Having 1.7.x or 1.8.x branches of Core Apps would be really convenient.
I personally do not see any problem in doing maintenance branches for modules. We already do it for the core platform, anyway.
All it takes is for you to be willing to invest time in doing it. 
That being said, do you have to release all the 2.3.2 modules? I thought only coreapp would be enough if it is the only one you have modified.
What tasks would be involved in the maintenance of - say - Core Apps 1.8.x?
For the core platform, we follow the steps here for maintenance releases: https://wiki.openmrs.org/display/docs/OpenMRS+Platform+Release+Process
In this instance do you mean “forward port” to the master branch? So every time we want to bring in something on 1.8.x we should have it done on master as well right?
I used back instead of forward on the assumption that the changes are already in master.
Yes you need to have the changes in master too.
As @dkayiwa says, you are more than welcome to maintain a release branch of any module you want; it’s just that we don’t do this preemptively.
But as Daniel also says, this means making the same changes to both the master branch and to the release branch (e.g. so that no feature appears in 1.8.3 and disappears in all later versions). Otherwise it’s just a fork (which you can do, but shouldn’t be hosted in the openmrs version of github or maven).
Yes, got it.
We are discussing this internally. We have brought quite a few changes valuable to the community into Core Apps 1.8 (as in through Ref App 2.3). We certainly won’t ever upgrade to Ref App 2.4 and will eventually jump straight to 2.5 or later (or migrate to Bahmni). It certainly makes a lot more sense to us to maintain a branch 1.8.x (and forward-port things to master) rather than having our own fork, which leads to all sort of troubles.
I’ll get back to you about this as soon as I can.
Ok sorry I got it wrong earlier, we are also rather on a variant of Core Apps 1.7 (not 1.8).
So I created a starting point for this branch 1.7.x here. This would be 1.7.1-SNAPSHOT.
I went off the last commit before Core Apps was made 2.0-compatible while bringing in multiple additional submodules, and I also got rid of the dependency on the distro (in the exact same way as it is done now on master.) And I made sure that this builds fine out of an empty .m2 
@dkayiwa, what would be the next step(s) to move this to the /openmrs GitHub repo instead of ours? I don’t think I have any write access right now.
@insiderish, let me know your thoughts.
@mksd if i created the branch, would you create a pull request, based on this branch, for your changes?
Yes sure. Please create it and I’ll do the PR as soon as I’m back at my computer (on my phone right now).
Sounds good.
Thanks @dkayiwa
Question: But why are the dependencies on 1.7.1-SNAPSHOT different from 1.7.1 release tag? An example is emrapi requires version 1.12 whereas 2.3.1 modules has version 1.11.1.
Simply put, if I compile branch 1.7.x and dump it in the 2.3.1 modules, it doesn’t work!
I’d expect the 1.7.x branch to have the same code base as tag 1.7 (https://github.com/openmrs/openmrs-module-coreapps/tree/1.7). Am I wrong?
Thanks
Andrew
I have pushed for EMR API v1.12 (instead of v1.11.1) because EMR API v1.11.1 depends on distro 2.3-SNAPSHOT and hence is a tag that can’t ever be built anymore. If upgrading EMR API to v1.12 is not possible for you, then I think we can PR to get this version down to 1.11.1 again.
In our experience upgrading EMR API to v1.12 is painless, but only you can tell if that’s not the case on your end.
Hey.
I was able to upgrade emrapi to v1.12.
I’m still required to upgrade appframework from the current 2.1 to 2.5. However, it blows up with this error:
“Exception is java.lang.NullPointerException Related cause: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘emrVisitService’ defined in URL [jar:file:/home/andrew/.OpenMRS/.openmrs-lib-cache/emrapi/emrapi.jar!/moduleApplicationContext.xml]: Cannot create inner bean ‘org.openmrs.module.emrapi.visit.EmrVisitServiceImpl#7cbaabcd’ of type [org.openmrs.module.emrapi.visit.EmrVisitServiceImpl] while setting bean property ‘target’; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘org.openmrs.module.emrapi.visit.EmrVisitServiceImpl#7cbaabcd’ defined in URL [jar:file:/home/andrew/.OpenMRS/.openmrs-lib-cache/emrapi/emrapi.jar!/moduleApplicationContext.xml]: Cannot resolve reference to bean ‘visitResponseMapper’ while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘visitResponseMapper’ defined in URL [jar:file:/home/andrew/.OpenMRS/.openmrs-lib-cache/emrapi/emrapi.jar!/moduleApplicationContext.xml]: Cannot resolve reference to bean ‘encounterTransactionMapper’ while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘encounterTransactionMapper’ defined in URL [jar:file:/home/andrew/.OpenMRS/.openmrs-lib-cache/emrapi/emrapi.jar!/org/openmrs/module/emrapi/encounter/EncounterTransactionMapper.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.openmrs.module.emrapi.encounter.EncounterTransactionMapper]: Constructor threw exception; nested exception is java.lang.NullPointerException:”
Any idea?
Thanks
Andrew
I think (apart from emrapi) required modules should have the same version numbers as release tag 1.7.
A few of them have been opportunistically upgraded for the exact same reason as what I said about EMR API v1.11.1.
Are you familiar with the SDK? If yes I can provide you with an openmrs-distro.properties file that is this enhanced 2.3.1 distro, already including the few upgraded modules + Core Apps v1.7.1-SNAPSHOT.
Here: openmrs-distro.properties.
Of course you need to have built the branch 1.7.x of Core Apps before setting up the server with above distro.