Skip to end of metadata
Go to start of metadata

*** DRAFT

Introduction

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.

Release Management

The release management team is responsible for the creating a testing branch from the development branch. Once the testing branch is created, then the release management team is responsible for deciding on what to merge from the development branch to the testing branch. Additionally, alpha, beta, and release candidate tags are created for testing by the testing team. Upon successful testing, a release is created.

Testing

The testing team is responsible for testing alpha, beta, and release candidates. If issues are found in the testing phase, then issues are reported back to the development team. If issues are found with the changes as merged to the testing branch, the original issue should then be reopened, and additional information given as to the failure with the code as committed.

There is also a sample testing matrix that could be employed during the testing phase: https://wiki.asterisk.org/wiki/display/~mdavenport/Functional+Testing+Matrix

Process Overview

Release Work Flow

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.

List of Commonly Used Modules

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

  • No labels