...
After OpenMRS 1.9.x was tagged, we started working on several new features for 1.10. One of those new features was a refactoring of order entry; however, since the order entry changes were not fully vetted and lacked clear product owners, what would have become 1.10 and get released over the next year ended up languishing for over a year and a half, stalling the OpenMRS release process. As a result, we accumulated at least 18 months of volunteer contributions into a version of OpenMRS that was considered "unreleasable". After several discussions amongst the developer community, we reached the conclusion that the changes to the order entry API were the primary blocker. This came up again at OMRS13, when we found a few implementations interested in rebuilding the order entry service in a manner that could meet real community needs and lay a strong framework for order entry going forward. Since the interested implementations had short timelines (shorter than we could accommodate releasing a version of OpenMRS and then working on order entry), we made a decision to alter the normal trajectory of OpenMRS. OpenMRS 1.10.x was branched directly from the 1.9.x tag and a new order entry service would be built within 1.10.x. The master branch, containing all of the community contributions (along with the Order Entry changes-to-be-made in 1.10.x), would be later released as 1.11.
...
- Plan a community-assisted upgrade for a willing implementation – i.e., we will need to get 1.11 running at an implementation to ensure that the community has confidence in it. To do this, we will need to go above & beyond our typical relationship with an implementation to get it successfully deployed. This means finding an implementation will willing to upgrade to 1.11 with the direct assistance of the OpenMRS developer community (e.g., perhaps a core dev on-site and regular communication with the dev mailing list to get them up & running with any/all bugs quickly addressed).