Release and Test Planning Procedure

Background

In order to ensure that JavaRosa's releases are stable, secure, and fully functional, the community follows standard code freeze/QA cycle procedures. Essentially, the process for a release looks like the following:

1. Developers pull the default branch from mercurial
2. Patches (active development) are submitted to the incoming server, merged to the default trunk
3. Patches are reviewed and approved (or amended by developers, then approved) by core committers
4. A release branch is started off of a certain point from the trunk with a specific intended version (JavaRosa 1.3 for instance) which has a required feature set. The current head is tagged ("javarosa_1.3.0alpha", for instance) That code is frozen (no new commits are accepted) until it is QA'd.
5. The release is run through a testing cycle based on the appropriate Test Plan template. Bugs are submitted and cataloged.
6. Bugfixes are submitted and approved in the standard Patch review process on the release branch
7. Once a sufficient number of fixes are in place, the branch is again tagged ("javarosa_1.3.0beta", for instance), code is frozen, and another testing cycle is complete
8. This process repeats until the bug set is either sufficiently minor that a release is acceptable.
9. The code is tagged as the appropriate release, ("javarosa_1.3.0", here), and the code is unfrozen for bugfixes. The branch is now a maintenance branch. New features should almost never be submitted to it, only bugfixes. Each branch maintains a linear set of changes for such bugfixes, each of which has been run through a test cycle (1.3.0, 1.3.1, 1.3.2).
10. New features are added to the default trunk and the process continues as normal.

Templates

The current testing template is located here