Release Process

This document describes the management and technical procedures that are followed before making an official Portico release. For the purposes of this document, all items of work are describes as tasks (whether they be new features, bugs, or anything else). Also note that not all tasks are necessarily code-related. For example, documentation requirements would also be considered tasks.

Overview of Process
The process of making an official release of the Portico Project involves five (5) development phases:


 * 1) Normal Development
 * 2) Release Scheduled
 * 3) Code Complete
 * 4) Release Candidate
 * 5) Final Release

Each of these phases and the processed involved is outlined below.

Normal Development
The majority of new feature development and project development occurs during this phase. Although not technically part of the release cycle, this is the phase from which the first of the release phases migrates.

At the beginning of each normal development phase, the core developers (see Contribution and Management Policies) are responsible for declaring which new features are to be implemented and which are to be left until the next version. This discussion should take place on the portico-developer mailing list. Membership to this list, and archives of discussions are to be publicly available. Input from the community is welcome and actively solicited for this process.

Release Scheduling
After an arbitrary amount of time, any core developer may call for release planning to begin. Unless there is an objection from another core developer (which would be resolved by a vote), the process of scheduling the next release begins.

During this phase, a triage of all the remaining tasks is performed. All those tasks deemed as necessary to complete the release are identified, and all other tasks are pushed to a later version. The triage process is managed by the Arbiter (see Contribution and Management Policies) or lead developer (whoever is willing to do so), however, decisions about the priority of a task are only made with input from the other core developers and the community. If there is a dispute on whether or not a task should form part of the release, a vote of the core developers is conducted on the developer mailing list (link). Developers are free to vote "neutral" or abstain from a vote.

Once the triage is complete, the final list of tasks will have been generated. At this point, a tentative release date should be set according to the amount of work remaining. After this point in time, no new features will be developed or accepted, except where they are on the list of remaining tasks. The one exception to this rule is for bugs. New bugs can still be identified and at the discretion of the core developers, added to the list of tasks for the release, regardless of severity.

Code Complete
Once all the known tasks associated with the forthcoming release have been completed, development moves into the "Code Complete" phase. From this point on, only newly identified bugs that are classed as critical or blocking by the core developers will receive development effort. Any other newly identified bugs of lesser priority will be pushed to the next release. Once code complete has been reached, a release candidate will be generated (see checklist below) and made publicly available.

Release Candidate Testing
Once a release candidate has been released, a minimum of one (1) week must be allowed for testing to occur (both by developers and within the community), and any new bugs to be identified.

As the codebase is now "code complete," only fixes for newly identified bugs of sufficient severity should be incorporated. If there are significant problems with the release candidate, it may be necessary to generate additional release candidate's incorporating the requisite fixes. Accordingly, this phase can occur multiple times. Once all known bugs associated with the release have been identified, and the latest release candidate has been in a known stable state and publicly available for at least one (1) week, progress to the final stage can occur.

Final Release
This is the final phase, involving the release of the stable code. In this, the repository is tagged and the final build artefacts are generated (see checklist below) and made publicly available. Following this, work moves back into the Normal Development phase. One final task for this phase is to generate the "New and Noteworthy" page on the website for this release. This page will outline all the major new features added in the past release and will help to inform the user community of what has changed and been added.

Release Checklist

 * Generate binary installers (will execute regression tests)
 * Update the API documentation on website
 * Generate New and Noteworthy Document
 * Update the Status/Roadmap sections of the website
 * Upload all installers to SourceForge and make publicly available
 * Notify the community via the portico-announce mailing list