|[eigen] Proposal for a 6 month release calendar|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: [eigen] Proposal for a 6 month release calendar
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 15 Jun 2012 13:28:28 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=2KH2BdwACW1LYye2lbAPRzHfWtyVn6zE6v9vOHceDlY=; b=eRam+G4In8hoB7WoFytsx5qonC4eZ0XXr5FL25hZ8PFljt78ENoS/fxkQoFbir1iGW +3bt5l0bvfwx7KdAMbRK7xaHpWlHwkIB3beI4hJ1p/JhF+vc3YdA2zDqyq/NmpY1+vnm 5LR8O/b1OrcfBynTKbaLYUYhnM3PiFIKm+DeEDUpoY4tfAxf5fnnyDCfb2+ISJ0EzBkL +qwed3xXCk1CIV9r7fcLYlt7uoSKWA4mVJaG/UKEWDaRaKSk4W1E1dlCz1kx53DisacH iMDQpjOAXnOiCFkxlBmJEy0/VBdQLRcuXH1AAPmjA7Em4/Q8ACs+cQfW4HwWuGlmWe/l 1SBg==
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
feature freeze: 15 september
code freeze: 15 october
beta release: 15 november
final release : 15 december
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
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
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?