[Bf-committers] 2.6 Release Cycle Proposal

[Brecht Van Lommel]

Hi,

Proposal seems good to me. Also would like to stress that I think an
important change to make is not just updating the b-con levels to fit
better, but really doing a time based release cycle.

>From this presentation about the google chrome release cycle:
https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch&pli=1

* The pace of the schedule sets the boundaries for the amount of work
that can be completed.
* It's important to have specific points in the schedule to review
features and cut scope.
* Establish clear expectations (and engineering practice) to
developers that any features not ready to ship will be disabled.

On Fri, Jul 29, 2011 at 1:59 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> If we need to do an 'a' release individualizer fixes could be applied
> from trunk rather then keeping trunk frozen *just in case* we need to
> do another release (could branch from the tagged rev and merge only
> the fixes from trunk).
>
> I'd like to know what others think about doing a release and
> unfreezing soon after ahoy (1-2 days).

I agree, better to unfreeze trunk nearly immediate and merge critical
fixes for a/b releases to a branch.

Brecht.