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.

Phases

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.

Decide absolute deadlines

The worst part about the last one was the indefinite freeze. We should have a freeze for 2 weeks, with a possibility of an extra 1 or 2 weeks and thats it. once we hit that deadline the RM decides whether to release or not.

Phase 2 - Feature Freeze

Manual

As much as I hate docs, but if we do a release the manual has to be 100% accurate and finished for the release build. There can be no todo's or fixme's.

Playback

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 (easier said than done depending on the feature - JdG), though ideally we should strive to have as many features "stable" as possible, obviously.

Voice

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.

Manual

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.

Publicity

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.

Packaging

Do we want to use 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.

Bug disclosure (?)

If any bugs are decided to stay in we need to make them known in a very obvious way.

Phase 4 - Long Term Maintenance

Any high priority bugs which can be relatively easily back ported to the release build should be and a minor release be done for it. There is no point having a build which we suggest newcomers use if it has bugs which could be fixed.