<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/Software+Configuration+Management+Policies">Software Configuration Management Policies</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mjordan">Matt Jordan</a>
</h4>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > <br>{note} <br></td></tr>
<tr><td class="diff-changed-lines" >Over the years, the Asterisk version numbers have changed. A lot. For anyone who has ever had to <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">written</span> <span class="diff-added-words"style="background-color: #dfd;">write</span> a script that parses Asterisk version numbers, we apologize. We'll try hard not to change it again. <br></td></tr>
<tr><td class="diff-unchanged" >{note} <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h1><a name="SoftwareConfigurationManagementPolicies-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="SoftwareConfigurationManagementPolicies-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 project's <a href="http://svn.asterisk.org/svn/asterisk" class="external-link" rel="nofollow">source control</a> 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 all currently supported 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 created and announced; and when a major version branch is made and the first feature 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 and a description of the <b>Mainline</b> branching model, 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="SoftwareConfigurationManagementPolicies-MajorVersionBranchTypes"></a>Major Version 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="SoftwareConfigurationManagementPolicies-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="SoftwareConfigurationManagementPolicies-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 when possible.</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="SoftwareConfigurationManagementPolicies-ReleasePolicies"></a>Release Policies</h2>
<p>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.</p>
<h3><a name="SoftwareConfigurationManagementPolicies-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. Each major version typically only has a single feature release (see <a href="#SoftwareConfigurationManagementPolicies-newfeatures">New Feature</a> policy below).</p>
<h3><a name="SoftwareConfigurationManagementPolicies-BugfixReleases"></a>Bugfix Releases</h3>
<p>New versions of Asterisk are released on a periodic basis from all currently supported major version 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 those branches.</p>
<p>Sometimes, a sufficiently critical regression will be detected that will warrant an immediate regression release. These releases are made from the previous releases's tag, as opposed to the major version branch.</p>
<h3><a name="SoftwareConfigurationManagementPolicies-SecurityReleases"></a>Security Releases</h3>
<p>When a security vulnerability is reported against the Asterisk project (typically by e-mailing <b>security@asterisk.org</b>), bug marshals will create a private issue 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 tags for security releases are made from the previous release's tag, and not from the major version branches.</p>
<h2><a name="SoftwareConfigurationManagementPolicies-FeaturePolicy"></a>Feature Policy</h2>
<h3><a name="SoftwareConfigurationManagementPolicies-BugFixes"></a>Bug Fixes</h3>
<p>Bug fixes are merged first into the oldest supported release branch that contains that particular bug. 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/graphviz4161202425474508979.png?contentType=image/png&delete=true'/></td>
<td class="confluenceTd" valign="top" width="75%">
<p>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.</p>
<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></td></tr></tbody></table>
<p><a name="SoftwareConfigurationManagementPolicies-newfeatures"></a></p>
<h3><a name="SoftwareConfigurationManagementPolicies-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>
<p>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.</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>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="SoftwareConfigurationManagementPolicies-MajorVersionStability"></a>Major Version Stability</h1>
<p>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.</p>
<p>What is a breaking change?</p>
<p>A breaking change is any that invalidates a previous configuration either implicitly or explicitly. Adding items to a configuration is not a breaking change as it does not invalidate any existing configurations. To that end, the following items should not be invalidated within a major version branch:</p>
<ul>
<li>AMI Actions and Events</li>
<li>AGI Commands and Responses</li>
<li>Dialplan Applications, Functions, and pattern matching rules</li>
<li>Configuration file settings</li>
<li>Realtime database schemas</li>
<li>CLI Commands and Responses</li>
<li>CDR/CEL behavior</li>
</ul>
<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Within a major version branch, there are times when a breaking change must be introduced - usually to fix a serious, critical bug within that branch. When this occurs, the UPGRADE text file delivered with Asterisk will be updated noting the change.</td></tr></table></div>
<p>The following items <b>can be changed</b> between minor versions in a major version branch:</p>
<ul>
<li>Log file output</li>
</ul>
<h1><a name="SoftwareConfigurationManagementPolicies-AsteriskVersionNumbers"></a>Asterisk Version Numbers</h1>
<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 version 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 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 write a script that parses Asterisk version numbers, we apologize. We'll try hard not to change it again.</td></tr></table></div>
</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/Software+Configuration+Management+Policies">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=21464277&revisedVersion=22&originalVersion=21">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>