dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Search | Go
Wiki > Main > ReleasePlanning (r1)

Release Planning

On this page I would like people to fill in general requirements for release planning. Specifically, I don't want individual bugs listed, I would like to have general requirements for each phase of a release attempt. At this time, this is not toward any specific release time, but rather an outline of what various people feel are important toward our next release whenever it may be. Some examples are already in the list below. Edit or, preferably, add steps and things we need to take into consideration, and then it can be trimmed back later once well populated.


Phase 1 - Pre Freeze

These are the things that should be true before we enter a feature freeze.

All major features "functional"

Every feature listed in the manual, and every feature we want to be listed in the manual works to a degree that a user can make use of it.

An outline of "goals" for the freeze has been planned.

Beyond this page, a list of current bugs should be accumulated that we hope will be fixed in the freeze, hopefully with priorities to be assigned before the freeze, and updated during, to denote which ones should prevent the freeze from ending, and which are acceptable for allowing in the 'release' but documented.

Phase 2 - Feature Freeze


By the end of the freeze, playback must be as stable as possible. Any features that may not work reliably (crossfade is a common example) may be disabled for the "Release" version, but left in the dailies, etc. The stable version doesn't have to have the full featureset of the current build, though ideally we should strive to have as many features "stable" as possible, obviously.


Voice is priority number 2, and should be as working as possible for the release. I think we're actually doing pretty well on voice right now.

Modular work

If possible, patches to "fix" issues in during the freeze should be kept. A plan needs to be in place for when work during the freeze increases instability, and we're approaching any set deadline. Basically, we should try to make it so each "fix" is as easily revertible as possible. This may not always be an option, but the release manager should be able to strip work if the current stage in that area is actually less stable. This can be done by walking revisions back through SVN, but it would be nice to keep patches around, so that attempting to just revert them in order can be attempted first. Another option is something like using git to keep separate developer branches, and then attempt to merge near the end of the freeze, rather than working on SVN head.

Phase 3 - Post-freeze.


Though ideally manual work would continue during the freeze, once a stable binary is available, the manual must be thoroughly checked to make sure it can match the build.


Several websites have mentioned an interest in knowing about our 3.0 release. Once the release binary is ready, we should notify them that a release is imminent once the manual has been cleared up.


Do we want to us RBUtil, or old install methods? This should be decided in advance, but once they're decided, we should make single-file downloads for each target for "New and one time installers" that include every file necessary for a "full" installation of everything we can provide for the release binaries. This means fonts, "official" themes, bootloader patchers, and a PDF of the manual, so that someone can just download it, and have everything the need or could want for a "Release" install.

A paragraph of text
r1 - 08 Jan 2008 - 23:50:29 - PaulLouden

Copyright by the contributing authors.