Major Version Branch Types

The Asterisk project currently defines two different types of major version branches: Standard and Long Term Support (LTS). The type of branch dictates the types of features that receive focus during that period of Asterisk development as well as their supported maintenance lifetime.

Standard Versions

When a Standard branch is being developed, all changes that improve the Asterisk project are candidates for inclusion. This includes fundamental architectural changes, modifications to APIs, and other substantial changes.

A Standard release receives bug fixes for a year after release, and security fixes for an additional year. At the end of this two year time span, branch maintenance is discontinued.

Long Term Support (LTS) Versions

When a LTS branch is being developed, the focus of development is upon improving stability and the end user experience. Major architectural changes are not prohibited but should be avoided when possible.

A LTS release receives bug fixes for four years after release, and security fixes for an additional year. At the end of this five year time span, branch maintenance is discontinued.

Currently Supported Branches

Please refer to the Asterisk Versions page for more information on specific branch lifetimes.

Release Policies

When a release is made, a tag is made from the major version branch, or, in the case of security or regression bug fix releases, from the previous tag for that major version. The types of releases are described below.

Feature Releases

The first release of a major version is a feature release, and contains all the new features developed for that new version of Asterisk. Each major version typically only has a single feature release (see New Feature policy below).

Security Releases

When a security vulnerability is reported against the Asterisk project (typically by e-mailing [email protected]), bug marshals will create a private issue on the issue tracker and work to resolve the problem. Patches are made against all release branches that are currently within their security fix timeline and are made available at http://downloads.asterisk.org/pub/security/, along with a security advisory describing the vulnerability. Note that tags for security releases are made from the previous release's tag, and not from the major version branches.

Feature Policy

Bug Fixes

Bug fixes are merged into all supported release branches that contain that particular bug. When dealing with multiple branches, it's hard to keep track of where comments are made so comments will always be made in the gerrit review for the lowest branch. The patch should therefore be submitted to gerrit against the lowest applicable branch, and cherry-picked to the other branches, including master. With controversial or large patches, it's highly recommended to submit only against the lowest applicable branch and wait for feedback before cherry-picking. This will save you the time and aggravation of re-cherry-picking your review after every comment. An Asterisk team member will usually give you the "OK to cherry-pick" comment when it's safe for you to do so.  Note that in some very rare cases, a bug fix may be deemed too intrusive in a particular branch. Such cases are discussed when the patches are proposed.

New Features

New features are classified as patches that either:

• Improve on existing functionality in Asterisk (better implementation, improved performance, etc.)
• Add new functionality to Asterisk

New features should follow the same procedure as bug fixes however they are, subject to the following conditions:

• Any new feature proposed for an existing release branch must have suitable test coverage using either the Asterisk Test Suite, the Asterisk Unit Test Framework, or both.

  Icon

  Tests are always good and encouraged, especially for new features. Having tests is a mandatory requirement for new features in release branches to minimize the risk of regression.

• The new feature or improvement must be backwards compatible with the previous releases in those major versions. That is, users upgrading from one point release to the next should not be aware of any new feature or improvement unless they want to use said feature. Some things that should not be changed naturally follow from this:
  • APIs that follow semantic versioning should not receive a major version increase.
  • Configuration and database schemas can be added to or updated, but users should not be required to update their configuration or databases.
• Any new features or improvements must be included in the first release candidate of a new version. First release candidate announcements must be made to the asterisk-users mailing lists, with at least a week of testing time allowed. If a new feature or improvement is deemed to cause an inappropriate burden on end-users, it must be removed from the release.

Generally, new features or improvements should always be done as new modules where possible, and those modules should be disabled if included in a release branch. If changes are necessary to the Asterisk core, all care possible should be given to not impact existing modules.

Note that if a new feature radically changes the architecture of Asterisk and the next planned major version branch is an LTS branch, you may be asked to defer the change until the next Standard branch is being developed.

Major Version Stability

Once a major version branch has been made, all effort shall be made by Asterisk developers to not introduce breaking changes into that major version.

What is a breaking change?

A breaking change is any that invalidates a previous configuration or changes the way in which an application interfaces to Asterisk either implicitly or explicitly. Adding items to a configuration or information presented to an application is not a breaking change as it does not invalidate an existing configuration or require modifications to a well-written application. To that end, the following items should not be invalidated within a major version branch:

• AMI Actions and Events
• AGI Commands and Responses
• Dialplan Applications, Functions, and pattern matching rules
• Configuration file settings
• Realtime database schemas
• CLI Commands and Responses
• CDR/CEL behavior

The following items can be changed between minor versions in a major version branch:

• Log file output

Asterisk Version Numbers

Asterisk uses three digits in its version number sequence:

major.minor.patch

• Major - denotes which major version branch the release was made from.
• Minor - denotes a release version. These increase sequentially for each release.
• Patch - denotes that the release was either a security release made from the previous release, or a release made to fix regressions or serious bugs detected in the release.