Reference Application 2.x releases are different than OpenMRS platform releases (like 1.11.0). Platform releases usually consist of alpha, beta releases and have Sprints to complete tickets in a short span of time. Reference Application 2.x is a collection of modules and hence its release consists of releasing all the modules planned to be included in the 2.x release and testing if all of them function collectively.
In the case of 2.4, the release is planned on March 31st, 2016. Though the testing might not be as extensive as a Platform release, a user acceptance testing is necessary. This is scheduled around mid – March to Late mid – March. This is a very short period of time but for this to happen all the modules that are planned to be released in 2.4 need to be in a release ready state and we need your collective collaboration on making this happen.
NOTE: This is an OpenMRS Talk “wiki-style” post. You can edit it by clicking the pencil icon in the upper right of this post near the date/time. This post will be constantly updated to indicate the state of the release process. People who make changes like releasing a module or any such information should please update this post with the status.
Release Modules
Note: The Points of Contact below have been mentioned based on the recent commits to the respective modules. If you have been mentioned as the point of contact, and are not sure if you are responsible for the respective module, you can update it by removing your name and updating it with the person responsible if you are aware of them.
Release modules - (In Progress) - Estimated Deadline: 10 March 2016 - module owners
@jdegraft, it’s great that you’ll be managing the release process! I’m looking forward to supporting where I can.
One concern I have is that the timelines laid out here are too tight, especially the idea that we’ll do UAT for 1 week and release the next day. (What about issues raised during UAT? Those will take time to address…)
Offhand, my recommendation would be to push all the deadlines a week earlier.
Actually, there’s one other thing: we need to be intentional about how we time this release with respect to the Platform 2.0 release +/- what Platform version we depend on.
The latest Reference Application release (2.3.1) is built on top of Platform 1.11.5.
There will be non-trivial work in updating this to work on top of Platform 2.0.
Currently the Platform 2.0 release is scheduled for “Q1 2016,” which could easily mean March (i.e. the same month that the Reference Application release is scheduled for)
I would say there are two options:
Keep the Reference Application 2.4 release in March, but base it on the Platform 1.11.x line
Delay the Reference Application 2.4 release by ~2 months, and base it on Platform 2.0.x
Personally I vote for 1 (releasing based on Platform 1.11.x in March) but I’d further say that immediately after Platform 2.0 and Reference Application 2.4 are released, we should immediately start working on a Platform 2.0-based Reference Application release (with no additional features), and aim to release it within a couple months (and not wait until September).
@darius I am asking from a point of ignorance so please enlighten me, if platform 2.0 is a big break from the 1.x line especially the Java 8 stuff then shouldn’t the RA therefore also be 3.0 in tandem since there is no backwards compatibility even if no new features.
As an implementor I would vote for 2.4 based on the 1.11.x branch in March as that would provide the fastest time to market for us.
@jdegraft thanks for providing some insight into the planned process.
@darius, I would vote for releasing based on Platform 1.11.x in March as well, as @ssmusoke mentioned the changes are big in Platform 2.0 and it might affect many modules and asking module owners to update their modules in a couple of months will be demanding of their time.
I agree with both @ssmusoke and @maurya about this, I just want to make sure we’re being intentional about this.
Particularly, we usually have tried to have the Platform releases offset from the Reference Application releases by a few months, so that we have time to incorporate the new platform in the refapp release. In this case the platform release is slower (because Platform 2.0 is big), but it makes sense to prioritize keeping the Reference Application release on schedule, over having it incorporate the latest platform release.