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

[Brecht Van Lommel]

Regrading the original mail in this thread, I completely agree with
being more strict in the week before release. That's a rule that is
supposed to be there already but we don't follow it well, so we can
agree as core developers to enforce that better for the next release.
The only thing I fear is that we'll be under time pressure again and
become lax again, but if there's 1 or 2 developers kicking others it
can be done.

On Tue, Jul 30, 2013 at 11:25 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> @Brecht
> re: branching stable (keeping trunk for development)
>
> This topic has come up before, IIRC Ton is against doing this since it
> means developers focus less on stabilizing and users who build are
> less likely to update svn and use the version of blender we will
> release (valid points IMHO).
> If we rename our 'release' -> 'RC', and '2.68a' -> 'release',
> then this is exactly what we do already (since the bugfix release is
> made from a tag of trunk).
> Though I worry too many issues get conflated and then we don't agree on basics.

If we can somehow turn the release into RC and 2.68a into 2.68 then I
think that is a step forward.

Maybe I should try to convince Ton about this.. in my opinion we can't
really focus on stabilizing and have trunk frozen at the same time,
either we continue bugfixing or we wait for critical issues.


Brecht.