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