...
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)
...
- 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).
...