利用者:Brecht/ReleaseCycle

Release Cycle

Proposal for 8 week release cycle.

Schedule

We use a fixed release schedule, to make the process more predictable, ensure regular releases, and to encourage good development practices. All deadlines will be set in advance.

The 8 week schedule is:

• 3 weeks, major new features can be added
• 2 weeks, minor improvements on existing functionality
• 2 weeks, stabilizing
• 1 week critical bugfixes only

It is the developers' responsibility to work out if their changes will be stable before the release, and if necessary split them up or work longer in branches. At the start of week 6, it should be clear if we can get the new features stable within 2 weeks. If this is not the case for some new features, they will be uncommitted and left for the next release.

Best is to verify and test your code well, get it reviewed, and commit early in the cycle. The last weeks of the previous cycle are a good time to get the design and implementation of bigger features reviewed.

Branches

Most power users are simply using trunk and not releases, so having separate branches for development and stable releases is not a viable option. We center everything around trunk, and let developers use (preferably short lived) branches when the features is too big or while trunk is locked.

If we keep the release cycle sufficiently short, developers know they can merge things soon. We should try to avoid branches that live too long. Features don't get good testing, it's demotivating for developers, and merging them destabilizes trunk too much. Split up things if it doesn't fit the release schedule.

Existing major branches should be merged in pieces if they risk destabilizing things too much. If code can't be stabilized in a few weeks, it simply should not go in trunk in one piece, but in steps.

Example

2.58 Schedule

Jul 4		Jul 25		Aug 8		Aug 22		Aug 29
Major features		Minor changes		Stabilizing		Critical fixes		Release