<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2176/25/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Release+Branch+Policy">Release Branch Policy</a></h2>
<h4>Page <b>added</b> by <a href="https://wiki.asterisk.org/wiki/display/~mjordan">Matt Jordan</a>
</h4>
<br/>
<div class="notificationGreySide">
<h1><a name="ReleaseBranchPolicy-Overview"></a>Overview</h1>
<p>This page details the various branches of Asterisk, the focus of development in those branches, and what patches are allowed in a given branch.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>This page is currently in draft status. Please do not comment on this page.</td></tr></table></div>
<h1><a name="ReleaseBranchPolicy-AsteriskConfigurationManagementandReleasePolicies"></a>Asterisk Configuration Management and Release Policies</h1>
<p>Development in the Asterisk project follows the <b>Mainline</b> branching model of Software Configuration Management. During a development year - typically kicked off at <a href="/wiki/display/AST/AstriDevCon" title="AstriDevCon">AstriDevCon</a> - new features and bug fixes are integrated into the Asterisk Subversion repository's trunk branch (hereafter referred to only as 'trunk'). At the end of the developer year, the Asterisk development team makes a new major version branch from the Asterisk trunk. From the major version branches, tags are made on a periodic basis and released as minor version releases of that major version.</p>
<p>See <a href="/wiki/display/AST/Asterisk+Versions" title="Asterisk Versions">Asterisk Versions</a> for the approximate dates when a given version's development is started; when beta releases are announced and made, and when a major version branch is made and the first release made from that branch.</p>
<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>For an excellent article on Software Configuration Management branching schemes, see <a href="http://www.vance.com/steve/perforce/Branching_Strategies.html" class="external-link" rel="nofollow">Branching Strategies by Stephen Vance</a></td></tr></table></div>
<h2><a name="ReleaseBranchPolicy-ReleaseBranchTypes"></a>Release Branch Types</h2>
<p>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.</p>
<h3><a name="ReleaseBranchPolicy-StandardVersions"></a>Standard Versions</h3>
<p>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.</p>
<p>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.</p>
<h3><a name="ReleaseBranchPolicy-LongTermSupport%28LTS%29Versions"></a>Long Term Support (LTS) Versions</h3>
<p>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.</p>
<p>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.</p>
<h2><a name="ReleaseBranchPolicy-ReleasePolicies"></a>Release Policies</h2>
<h3><a name="ReleaseBranchPolicy-FeatureReleases"></a>Feature Releases</h3>
<p>The first release of a major version is a <b>feature release</b>, and contains all the new features developed for that new version of Asterisk.</p>
<h3><a name="ReleaseBranchPolicy-BugfixReleases"></a>Bugfix Releases</h3>
<p>New versions of Asterisk are released on a periodic basis from all currently supported branches, typically every 4 to 6 weeks. These Asterisk releases are <b>bug fix</b> releases, and contain bug fixes for reported <a href="https://issues.asterisk.org/jira" class="external-link" rel="nofollow">issues</a> against the Asterisk project.</p>
<h3><a name="ReleaseBranchPolicy-SecurityReleases"></a>Security Releases</h3>
<p>When a security vulnerability is reported against the Asterisk project (typically by e-mailing <span class="error">[security@asterisk.org]</span>), bug marshals will create a private issues on the <a href="https://issues.asterisk.org/jira" class="external-link" rel="nofollow">issue tracker</a> 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 <a href="http://downloads.asterisk.org/pub/security/" class="external-link" rel="nofollow">http://downloads.asterisk.org/pub/security/</a>, along with a security advisory describing the vulnerability. Note that security releases are made as a point release from the previous release tag, and not from the release branch.</p>
<h2><a name="ReleaseBranchPolicy-FeaturePolicy"></a>Feature Policy</h2>
<h3><a name="ReleaseBranchPolicy-BugFixes"></a>Bug Fixes</h3>
<p>Bug fixes are merged first into the oldest supported release branch. The bug is then merged into each of the subsequent supported release branches, until finally being merged into trunk.</p>
<table class="sectionMacro" border="0" cellpadding="5" cellspacing="0" width="100%"><tbody><tr>
<td class="confluenceTd" valign="top" width="25%">
<img src='/wiki/download/temp/graphviz883735281308953832.png?contentType=image/png&delete=true'/></td>
<td class="confluenceTd" valign="top" width="75%">
<ul>
<li>A bug is reported against Asterisk 1.8. The current supported branches are Asterisk 1.8, 10, and 11. The patch is merged first into the 1.8 branch, then the 10 branch, then the 11 branch, and finally trunk.
<div class='panelMacro'><table class='tipMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/check.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>See <a href="/wiki/display/AST/Subversion+Usage" title="Subversion Usage">Subversion Usage</a> for more information on how to merge bug fixes between branches of Asterisk.</td></tr></table></div></li>
</ul>
</td></tr></tbody></table>
<h3><a name="ReleaseBranchPolicy-NewFeatures"></a>New Features</h3>
<p>New features are classified as patches that either:</p>
<ul>
<li>Improve on existing functionality in Asterisk (better implementation, improved performance, etc.)</li>
<li>Add new functionality to Asterisk</li>
</ul>
<p>New features are only accepted in trunk. New features should not be added to release branches, unless first approved by the branch maintainers (this is highly unlikely, unless the new feature exists solely in a stand alone module).</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Why are new features not allowed in release branches? We debate this policy often, but the reasoning goes:
<ul>
<li>New features require significant testing efforts that are better handled through the yearly beta process.</li>
<li>New features run a greater risk of perturbing the existing code base, making the risk of injecting negative effects into production systems greater.</li>
<li>New features create a 'moving target' for system administrators and system integrators, making upgrades for bug fixes difficult and costly.</li>
</ul>
</td></tr></table></div>
<h1><a name="ReleaseBranchPolicy-AsteriskVersionNumbers"></a>Asterisk Version Numbers</h1>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Over the years, the Asterisk version numbers have changed. A lot. For anyone who has ever had to written a script that parses Asterisk version numbers, we apologize. We'll try hard to not to change it again.</td></tr></table></div>
<p>Asterisk uses three digits in its version number sequence:</p>
<p><em>major</em><b>.</b><em>minor</em><b>.</b><em>patch</em></p>
<ul>
<li><b>Major</b> - denotes which major branch the release was made from.</li>
<li><b>Minor</b> - denotes a release version. These increase sequentially for each release.</li>
<li><b>Patch</b> - 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.</li>
</ul>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Release+Branch+Policy">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Release+Branch+Policy?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>