github release procedure

[deadalnix]

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 ».