Re: [eigen] Proposal for a 6 month release calendar

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

I know I've been away for over a year now and I have very little say
in things, but here's just a random suggestion: you might be
interested in the "release train" model, first pioneered by the Chrome
team, quickly adopted by Mozilla as this model is so powerful that
once your main competitor does it, you have basically no choice but to
follow suit.

The idea is that you have N "channels" (for example you could have N=3
channels: 1) trunk, 2) beta, 3) release) are developed simultaneously,
and at fixed intervals, each channel gets moved into the next (more
"stable") channel, for example trunk moves into beta and beta moves
into release, and from there on trunk heads into a new version.

The upside is that there is never a freeze, so you can have as
frequent releases as you want without slowing down development. It
means a model where instead of being sometimes in development mode and
sometimes in stabilization mode, you're constantly in a mix of, say,
80% development and 20% stabilization.

The downside is that this incurs some work, to move code around from a
channel to another etc.

I'd be happy to serve as "release engineer" for Eigen as a way to get
back into Eigen work a bit, so if you're interested in this model, i
can execute it for you.

Benoit

2012/6/15 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> Hi list,
>
> now that the 3.1 release is ready, it's time to think about what to do next.
>
> Beside technical features and MPL2 relicensing, I think it would be
> nice for both the developers and users to define a strict release
> calendar.This should prevent from infinite delays between the
> releases. For instance we could imagine a 6 months based release plan,
> with a summer and winter releases. More precisely we could imagine
> something like:
>
>
> Winter release:
>
> feature freeze:  15 september
> code freeze: 15 october
> beta release: 15 november
> final release : 15 december
>
> Summer release:
>
> feature freeze:  15 march
> code freeze: 15 april
> beta release: 15 may
> final release : 15 june
>
>
> Here "feature freeze" means that at that time the list of features
> that will made it for the next release have to be fixed with a
> realistic schedule.
>
> At "code freeze", we can refine the list of features by delaying the
> ones which are not advanced enough. It could also be accompanied by an
> alpha release. Then between the code freeze and beta release, the
> commits should be focused on stabilization, bug fixes and
> documentation.
>
> What I'm not sure is about the creation of a new branch. Should it
> happen at code freeze? at the beta release? or simply when it becomes
> useful, i.e., when someone want to seriously start working on features
> for the next release?
>
> If you agree with the general idea, we can of course adjust its
> implementation. In this case, we should also define some roles. Who
> are in charge of accepting, delaying, or rejecting feature proposals?
> We would probably also need a "release manager" in charge of ensuring
> that the planed schedule will be followed, etc.
>
>
> What do you think?
>
>
> cheers,
> Gael
>
>