+1 to continuing with the release branch we have. I don't think that anybody is aiming to cause instability on the develop branch. We are all designing, writing code, refactoring, and writing exhaustive tests to the best of our ability to ensure high quality. We have to accept that there will sometimes be unforeseen consequences; that is the reality of working on a complex enterprise product. I think that it is unfortunate on this particular release we have seen as many critical issues as we have, but I do not think there is anything fundamentally wrong with our workflow. I think if anything, cutting the release early and allowing ample time to identify issues is a very good thing. Yes, in theory the develop branch should be releasable at any given moment, but in reality there is sometimes a feedback delay where issues arise after some time. I think our current process of cutting a branch and cherry-picking fixes for issues found allows us to deal with this delayed feedback.
The issues here to me are more around the delayed feedback time (issues found by very rare race conditions that don't arise often) and a lack of existing test coverage for many of our features. I do believe that everyone who has been committing refactored or new code is doing their due diligence to write tests, but it is not always easy to identify where test coverage gaps exist. We will of course continue to fill those gaps as we find them. Do you have other ideas on how to make develop more stable? Again, I personally feel people are doing their best to write new tests and review code - to me this is not a process problem (more like a tech debt/ease of refactoring problem) but I'm definitely open to discussion. Ryan
