Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

The Asterisk release process involves a team of people from the Asterisk community which work together to move through the release process. There are three teams which are responsible for aspects of the release process, which include:

  • Development
  • Testing
  • Release Management
Development

The development team is responsible for resolving and submitting code to the development branches (e.g. branches/1.8) and to trunk.

...

Process Overview

Gliffy Diagram
alignleft
nameRelease Work Flow
version3

Issue Severity Definitions

  • Critical
    • caused serious data loss, or introduced a security hole on systems
    • regression from previous release, or within the beta or release candidate process
    • commonly encountered crashes
  • Grave
    • made Asterisk unusable or mostly so, or causes data loss
    • deadlocks in commonly used modules
    • crashed, or deadlock which are commonly encountered (limits ability to use Asterisk)
  • Serious
    • bugs which limited or hindered functionality in commonly used modules
    • affected or broke the build process (i.e. unable to compile under CentOS)
    • crashes or deadlocks which are not easily reproduced (one-offs)
  • Important
    • a bug which had a major effect on the usability of a module, without rendering it completely unusable to everyone
  • Normal
    • the default value, applicable to most bugs
  • Minor
    • a problem which doesn't affect the modules usefulness and is presumably trivial to merge

TODO Continue to refine the definitions of issue severity.

...

TODO: Define modules we would consider core, or commonly implemented

  • chan_sip
  • chan_iax2
  • app_dial
  • etc...

Alpha (3 week window)

What issues are permitted to be considered for including in the testing branch:

  • Critical
  • Grave
  • Serious
  • Important
  • Normal
  • Minor

Beta (3 week window)

What issues are permitted to be considered for including in the testing branch:

  • Critical
  • Grave
  • Serious

Release Candidate (2 week window)

  • Critical

Process Description

  • After issues are resolved by the development team, the release management team, on a regular basis (1-2 times per week) would meet to evaluate the commits to the development branch for inclusion in the testing branch. Based on where testing is in the process, issues would be evaluated to their suitability for inclusion in the testing branch.
  • In the Alpha test phase, most bug fix issues can be committed to the testing branch, except those which touch core parts of Asterisk, or which make large scale changes across the code base.
  • Once the Alpha test phase is complete, the Beta phase takes over. Only Critical, Grave, and Serious issues are allowed to be committed at this point. The release should be getting tightened up and serious regressions or functionality changes are to be resolved and committed to the testing branch.
  • After the Beta phase is complete, we move to the Release Candidate phase. During this phase only Critical issues are evaluated for inclusion in the testing branch, which would include things like regressions from previous versions, code instability, or security issues.
  • During each of the phases, tarballs and packages would be created for each of the Alpha, Beta, and Release Candidates to promote testing, and permit a simpler upgrade path.
  • The testing team would test the tarballs / packages and report issues found during testing back to the development team to resolve. Issues found with specific commits that were merged into the testing branch would then cause the /Resolved/ issue to be updated and for the developer to resolve the regression, or breakage that the commit introduced. The tester would be responsible for providing all the information required by the developer to reproduce the issue, or debug and resolve the issue.

Ideas / Things To Implement / External Information