System information

number increasing by one each time a new feature release was created. The goal was
to provide new feature releases every 3–4 months (which would be branched from
trunk), providing a shorter and clearer upgrade path for administrators. If you needed
a new feature, you’d only have to wait a few months and could then upgrade to the
next branch.
Tags from these branches look like this:
• 1.6.0.1 -- 1.6.0.2 -- 1.6.0.3 -- 1.6.0.4 -- etc.
• 1.6.1.1 -- 1.6.1.2 -- 1.6.1.3 -- 1.6.1.4 -- etc.
• 1.6.2.1 -- 1.6.2.2 -- 1.6.2.3 -- 1.6.2.4 -- etc.
Figure 2-2 gives a visual representation of the branching and tagging process in relation
to Asterisk trunk.
Figure 2-2. The Asterisk 1.6.x release process
So, so far we have branches, which are 1.2, 1.4, 1.6.0, 1.6.1, and 1.6.2 (there is no 1.6
branch). Within each of those branches, we create tags (releases), which look like
1.2.14, 1.4.30, 1.6.0.12, 1.6.1.12, and 1.6.2.15.
Unfortunately, it ended up not working out that 1.6.x branches were created from trunk
every 3–4 months: the development process has led to a minimum release time of 6–8
months. Not only that, but the 1.6.x numbering methodology adds problems of its
own. People got confused as to what version to run, and that the 1.6.0, 1.6.1, and 1.6.2
branches were all separate major version upgrades. When you increase the number
from 1.2 to 1.4, and then to 1.8, it is obvious that those are distinct branches and major
version changes. With 1.6.0, 1.6.1, and 1.6.2, it is less obvious.
The New Release Methodology
The development team learned a lot of things during the 1.6.x releases. The idea sur-
rounding the releases was noble, but the implementation ended up being flawed when
put into real use. So, with Asterisk 1.8, the methodology has changed again, and will
look a lot more like that used in the 1.2 and 1.4 releases.
Asterisk Versioning | 27