Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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, 

  1. Move all unresolved (e.g., "Ready for work") tickets with fixVersion = 1.11 to 1.12
  2. Revert any post-1.9 changes to order entry within master
  3. Merge 1.10 changes (new order entry) into master
  4. Branch 1.11.x off of master, making master 1.12
  5. 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
  6. 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).
  • No labels