| Patch Release process - How does the patch release process impact
|
| 3.3.1 release will be before 3.4 3.3.1 release includes the fix for Malawi bug - addition of two
- Testing for this Malawi bug fix may be difficult because it is not always reproduced
- Testing would be verification that the fix has not broken anything else
- Happy path requisition test cases
- Patch release testing would focus on testing the component, but there is still a risk that other components are impacted by the bug fix
- Default testing by component unless we know that the bug fix impacts other components
- Testing would be determined by team (devs and QA) to ensure complete testing for the patch release
- Malawi would still conduct their own UAT for the patch release
- Are we planning to have release candidates for the patch release?
- Since we are only focusing on a few bug fixes for the patch release, then it doesn't make sense to have a release candidate process for a patch release
- If we fix bugs and deploy a patch release, and new bugs are found, what is the process?
- Another patch release 3.3.2
- Or Malawi doesn't take the patch release and waits for the 3.4 release
- For 3.4 release, dev teams should not work on new features, they should still focus on release candidate testing and bug fixes
- Feature flags will need to be in use before we can get to a point where dev teams can work on new features during the testing process
- For 3.4 release testing, devs should not work on any new features that would need to be pushed to the reporting repositories, or it could cause bugs that will need additional work
|