Continuing the discussion from Volunteer to be the OpenMRS RefApp 2.5 Release Manager:
@burke @darius @paul @dkayiwa @wyclif
Apologies for missing the dev call as I was on the road, but I have serious concerns about Ref App 2.5 being released on Platform 2.0, which is a Java 8 + lots of new features great but does not provide a pragmatic and practical upgrade path for implementers like Uganda which have ~350 sites with 1000 more planned. These sites will live for at least 2-3 years, and moving to platform 2.0 requires us to dump all current investment, rip out all our existing installations and replace them which is not feasible.
I would like to ask if the community leadership can consider Ref App 2.5 remaining on the 1.11.X branch to bring it to feature completeness at least as a complete replacement for legacy UI, and a Ref App 3.x line based on Platform 2.0 My understanding of semantic versioning, is that any point releases are somewhat backward compatible, but this is an overhaul.
@ssmusoke the good news is that, all the reference application 2.5 modules are platform backwards compatible. Putting it in another way, you can just replace platform 2.0 with platform 1.11.x and all runs well. For an example, get all the module versions running on platform 2.0 at http://uat01.openmrs.org:8080/openmrs/admin/modules/module.list and run them with platform 1.11.x to confirm the above.
So as more features are put in the reference application modules, they will still run well in lower platform versions like 1.11.x and hence you can continue using them in the Ugandan distribution. Which should be fine because you do not use the reference application out of the box. You just use its modules in a custom distribution.
@dkayiwa That is a partial relief. Additional questions: How long is the compatibility is expected to last, and when do implementors have to start plan on moving to platform 2.x when it happens.
Specifically in the Uganda case, the final switchover from 1.6.x will probably be completed in 2017, hence its important to get a sense of what the upgrade path is from there.
In principal, we support up to three latest releases of the platform. But practically, i have seen modules that were for instance made to still run on 1.6 even after it was at EOL.
Implementers are encouraged to move onto platform 2.x as early as it is convenient and practical for them.
On another note, how many modules in your distribution, do not run on platform 2.0?
Adding this link here to illustrate the concerns that I raised Update CI builds to build with Platform 2.0