[Bf-committers] 2.6 Release Cycle Proposal

[Sergey I. Sharybin]

Hi,

I'll agree with Campbell. It'll be more convenient for some developers 
(for example, me).

This even can work in such way:
- Trunk is never frozen
- Two weeks before release we create new branch (or replacing branch 
from previous release).
- In trunk usual work could happen.
- In that separated branch last changes, fixes, stabilization, blah blah 
happens.
- Some individual fixes can be merged from trunk to that pre-release branch.
- After release tagging happens based on that pre-release branch.

It's just idea.

And about proposal. It can't totally get us free from corrective 
releases, imo. Sometimes we're updating libraries and time to time 
errors happens when preparing new libraries -- wrong configuration, 
wrong compilation flag, forgotten feature to be included. Such things 
can be handled by corrective releases, but maybe someone got better 
ideas to handle such kind of problems?

Campbell Barton wrote:
>
> Hi Thomas, This seems good to me, at least - at least we can go ahead
> with it and make minor changes if needed.
>
> I'd like to raise a topic which isn't addressed in you're proposal.
>
> By taking more care to stabilize before release I think we could
> change how we freeze trunk.
>
> Currently we do a release:
> - freeze before release
> - release ahoy
> -  platform maintainers get builds made
> - official announcement
> - keep trunk (mostly) frozen for ~1week to see if we need an 'a' version
>
> I worry that we take too much time keeping blender frozen since this
> can take approx 3 weeks and with the proposal to do better tested
> releases, this will take longer.
>
> 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).
>


-- 
With best regards, Sergey I. Sharybin