Release and Test Planning Procedure
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:
- Developers pull the default branch from mercurial
- Patches (active development) are submitted to the incoming server, merged to the default trunk
- Patches are reviewed and approved (or amended by developers, then approved) by core committers
- 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.
- The release is run through a testing cycle based on the appropriate Test Plan template. Bugs are submitted and cataloged.
- Bugfixes are submitted and approved in the standard Patch review process on the release branch
- 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
- This process repeats until the bug set is either sufficiently minor that a release is acceptable.
- 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).
- New features are added to the default trunk and the process continues as normal.
The current testing template is located here