On Friday, 4 January 2013 at 19:30:29 UTC, Rob T wrote:
Terminology aside, we need to differentiate between bug fixes that do not introduce new bugs vs bug fixes that may introduce new bugs *or* break existing code for the current release version. We also *have* to prevent new features and structural changes (destabilizers) from leaking into a stable release.
Understood. The things is that it is more dependent of the code than of the bug itself.
Basically, it say that we should refuse risky bug fixes in released versions, and fix them into master. This probably should be specified at some point, but this is quite badly defined now, and I'm not sure this is really important to define this before actually using the process.
I'd go for a use you judgment here, or some very generic guideline like « if the bug fix require important refactoring, or change the behavior of an existing feature, then it should only be fixed in master ».
