[Dev] Alpha releases [Was : Phases and 0.7 milestone schedule]

[Philippe Bossut]

Hi,

Alec is bringing up the Alpha release process.

Alec Flett wrote:
> This is what is I think most interesting to me personally, and what I 
> think could could mean the difference between regular old milestones 
> (like we do now) and real "releases" My personal take on two months 
> milestone/alpha releases:
> 1) We, as a team, anticipate an upcoming milestone/alpha release 
> within 2-3 weeks of the actual release. This means we delay risky 
> fixes until the beginning of the next milestone. I would hope that 
> this "buckle down" period is identified as a part of the milestone 
> schedule from the get-go.
> 2) In the last week (?) of the release, the product release team 
> identifies the critical bugs necessary for the milestone and stops 
> accepting most "easy" fixes.
> 3) The development team doesn't try to accomplish too much in one 
> milestone. For instance, if we finish the bulk of the dashboard phase 
> 1 work in the first 3 weeks of milestone 1, then we stop working on 
> dashboard in milestone 1 and focus on bringing other key tenets up to 
> milestone 1 level - or we make more robust tests, or we do 
> architectural planning for milestone 2, etc etc..
I agree with all of this on a general level: we need to find a process 
to stabilize the release in the end of cycle.

There are 2 ways of doing this:
- policing the commits: that's basically Alec's proposal here above
- branching: used in other Open Source projects (see Fogel's)

I think we can go away with policing right now because we do not have a 
lot of outside contributors with commit privileges. We can therefore 
hold on patches during the end of cycle phase. Note that this process 
may stall some developers (working on feature straddling 2 releases for 
instance). Those can always create their own working branch (as Andi did 
at the end of 0.6 for instance) but that's a burden on them to merge 
everything back once the release is declared.

Branching is less constraining from a development standpoint but there's 
the added burden of committing to 2 branches for a substantial amount of 
time, something we may want to avoid right now. Eventually (when we have 
a big enough community of committers), branching might be the only way 
to go though.

Cheers,
- Philippe