Background
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.
Goal
The goal of this Sprint is to get all the community contributions over the past 2 years vetted & released as version as OpenMRS Core 1.11.
Steps
The goal of this Sprint is to roll back the post-1.9.x order entry changes within master, merge 1.10.x changes (basically 1.9 + new order entry service) into master,
- Move all unresolved (e.g., "Ready for work") tickets with fixVersion = 1.11 to 1.12
- Revert any post-1.9 changes to order entry within master
- Change @since 1.10 to @since 1.11 within master for any changes that haven't been back ported.
- Merge 1.10 changes (new order entry) into master
- Branch 1.11.x off of master, making master 1.12
- Make a pass through every 1.11 tickets, creating entries for release notes and identifying complex changes that need additional testing
- Create optional release notes entry (either in each ticket, if Chris Power has given us a way to do this in JIRA; otherwise in a notes.openmrs.org page) for every ticket in 1.11
- Be sure to capture new features, data model, and API changes.
- Be sure to capture changes that could affect module developers
- Label complex tickets with "1-11-complex"
- Complex tickets are those that involve changes or new features that either touch critical parts of the application or involve relatively large changes that could have broken over time. Basically, anything that is not a very simple change should be marked as complex.
- Create optional release notes entry (either in each ticket, if Chris Power has given us a way to do this in JIRA; otherwise in a notes.openmrs.org page) for every ticket in 1.11
- Per Darius, "Test the heck outta 1.11" (i.e., needs to be ticket-driven, meaning that we work through all of the tickets contributing work to 1.11 and test that their fix or new feature is working)
- Set up a testing site that approximates a real-world implementation (modules & content from a real implementation)
- Create small groups of tickets (bug fixes and/or new features) and then divvy those out for implementers/developers to test on the test site
- 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 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).