Nice work on this release!
For anyone who is new to reading the Core Framework release notes, I wanted to share some context on how to interpret the loooong list of bug fixes–56 bug fixes in this release alone. Some of these were real live bugs, and health workers will have a better experience once the technical teams supporting them upgrade to 3.7. On the other hand, many of the bugs in this list have never been encountered in a real live deployment. That may sound counter-intuitive, but there’s a good reason for it if you understand the release process.
When a Core Framework developer adds a new feature (1 in this release), improvement (18 in this release), performance fix (11 in this release), or addresses another technical issue (14 in this release), these changes to the code base sometimes unintentionally break something else. As this blog post on testing at Medic Mobile explains, there’s technical infrastructure and a bunch of organizational practices in place to catch these accidental problems, which are called regressions. When a new regression is identified, we create a new issue to describe it, label it as a bug, and make sure someone fixes it before the new code is ever released.
What does this all mean for the user experience? Basically, it would be a mistake to look at a long list of bugs in the release notes, and conclude that so far health workers were experiencing all of these bugs. In practice, we are catching and fixing some real live bugs with each new release. But more often, a long list of bug fixes is an indicator that we’re making significant changes to the code base, and that the testing process is thorough enough to catch issues before they ever make it into production.