[Bf-committers] Avoiding regressions, changes to the release cycle.

David Jeske davidj at gmail.com
Wed Jul 31 07:00:22 CEST 2013


On Tue, Jul 30, 2013 at 7:43 AM, Ton Roosendaal <ton at blender.org> wrote:

> That's why we added the 'BCon' cycle, where the last 2 cycles were meant
> for everyone to stop coding new stuff for 3+ weeks, and focus on
> stabilizing and fixing and testing of trunk (and *not* work on branches).
>

... or you could consider using the scheme most commercial projects use..
which is to freeze a tag/branch, build a binary, make the binary widely
available for whoever does testing as a binary. When regressions are
discovered, their fixes are committed to trunk, and before RC2
release-master cherry-picks those bugfixes into the release branch and
makes a new RC2. This iterates until the RC## stops getting show-stop
reports, then it hits release.

RC1 *binary* after being tested with devs, could be put on the website for
a week or two, letting entheusiasts test and report bugs so the next "real"
release doesn't have them.


More information about the Bf-committers mailing list