Asterisk, and other worldly endeavours.

A blog by Leif Madsen

About the new Asterisk versioning method


Recently I have been seeing more and more questions about how Asterisk is being released now, and what the 1.6.x versions really mean. I’ll try and clear up some of your questions and make it more clear as to how Asterisk versions work. First, lets talk about the Asterisk 1.2 and 1.4 branches.

Previous release methodology

When we just had Asterisk 1.2 and 1.4, all new development was carried out in trunk (it still is) and only bug fixes went into the 1.2 and 1.4 branches. Currently, the 1.2 branch has been marked as EOL (End of Life), and is currently only receiving security updates. Bug fixes are reserved for the 1.4 branch. This means that until 1.6 came along, all new development was done in trunk, without the ability for people to get access to new features and functionality until the 1.6 branch was created. It’s not to say the new functionality wasn’t available, but with all the changes that can happen in trunk, running a production server based on it would require a very Asterisk savvy (and C code savvy) administrator.

Before we talk about 1.6, lets make sure we understand what trunk, branches, and tags mean.

Branches, and Tags, and Trunk; oh my!

Asterisk development is basically a linear process. All changes happen one after the other, and new features are always put on the end. This is referred to as trunk. All the latest changes to core Asterisk code, new features, and major changes take place here. This is why running trunk in production is not recommended, because the developers essentially have free reign as to what goes in here.

Note: with the advent of review board, the larger commits that go into trunk are of much higher quality, as large changes are not put into trunk without any sort of peer review. The review board application allows these larger changes (such as new features, major core restructuring changes, etc.) to be reviewed by other developers to find common coding issues that would otherwise have had to be found in the wild.

Like a tree, the branches grow from the trunk. These branches are referred to as 1.2, 1.4, etc. A branch is a snapshot of the trunk at the time of creation, and from there, has its own timeline. When a bug is found, fixed, and resolved, the resulting commit is then placed into trunk, and any branches that it effects. When a new feature is created, it is only put into trunk, thereby leaving the branches in a relatively known state that is safe for production use.

From a branch, we create snapshots in time called tags. These tags are the version numbers and tar ball files you can download from the Asterisk.org website. These tags are numbered releases that never change, such as 1.4.18, 1.4.22, etc. In image 1.1, you can see a visual representation of the Asterisk branching and tagging process where the x-axis represents time.

Image 1.1

Image 1.1 - Visual representation of Asterisk release branching and tagging.

Understanding the Asterisk 1.6 release process

With the advent of Asterisk 1.6, the release process has differed slightly, in that there are multiple 1.6 branches supported at any given time. The reason for this is because the time frame between the creation of the 1.0 & 1.2 branches, and the 1.2 & 1.4 branches was so great (approximately 1 year in the former, and 2 years in the latter!) that new features would sit in trunk, and many changes would take place over that period of time. Due to the rapid development of Asterisk, these changes were grandiose and thus the user experience between these releases were such that major changes had taken place. Backwards compatibility was difficult to maintain, and simply, who wants to wait 3 years to get the next great feature?

So with Asterisk 1.6, a new release process that allows branches to be created in a more regular fashion (approximately 6-8 months) was developed. Whenever a branch is created, we now update the 3rd most significant digit, which represents a new branch with new features, and the 4th most significant digit is now the tag number in that release. So for example, we have the branch Asterisk 1.6.0, which is a branch created from trunk at a period in time, and within that branch, bug fixes are performed, but no new features are added. The tags from this branch will be version numbers such as 1.6.0.0, 1.6.0.1, 1.6.0.2, etc. Then some period in time, a new branch will be created from trunk such as 1.6.1 (note that the 3rd significant number has increased by one). Within this branch will be new features and changes — that different of the 1.6.0 branch. Within the 1.6.1 branch, we’ll have tags just like all our other branches, such as: 1.6.1.0, 1.6.1.1, 1.6.1.2, etc.

This process continues throughout the lifetime of the 1.6 series of Asterisk. The trunk continues to have development, new features merged and potential core changes to make Asterisk more efficient (which would otherwise be deemed too invasive for a release branch) are committed. The regular release nature of this process allows less drastic changes between major versions (and note that the difference between a 1.6.0 and a 1.6.1 *is* considered a major version upgrade, similar in nature to an upgrade between 1.2 and 1.4, but not quite so drastic), and access to new features on a more regular basis. Because these are considered a major change between versions, it is in your interest to read the UPGRADE-1.6.txt files in your Asterisk source, and to test thoroughly before deploying in a production environment.

It should be noted that at any given time, there will be at least 3 branches of the 1.6 nature maintained. That means bug fixes and maintenance will be performed on your preferred branch for an extended period of time. For example, because there can be code refactoring, and core changes between 1.6.x versions (where x is the major version number), you may wish to maintain your production system on the 1.6.0 branch while your development system is running the 1.6.1 series. This way you don’t have to worry about moving your 1.6.0 system immediately to a 1.6.1 based branch as soon as it is created. Image 1.2 shows a visual representation of the 1.6 release process, which should look similar to the release process between 1.2 and 1.4. The x-axis still represents time, but in this case, time is not over quite so long a period.

Image 1.1 - Visual representation of the Asterisk 1.6 release process

Image 1.2 - Visual representation of the Asterisk 1.6 release process

So which version do I use?

It always comes down to the question of, “so which version do I use?” and this can be a tricky one to answer. It probably boils down to what features you need to utilize. By checking the CHANGES file in your Asterisk source tree, you can see what changes have happened between each of the various branches (i.e. the differences between 1.6.0 and 1.6.1). While writing this article, I was asked by someone on IRC the question, “What version do you recommend?”, and the answer I gave was, “I recommend the version that has the features you require, and that passes the testing you have done prior to rolling it out”. He followed up with, “But they all have the feature I require!”, to which I responded, “Do some forward planning, and try to determine that the version you pick has the features you may possibly require in the future so that you don’t have to re-architect your system sooner than you want”. This can save you a lot of time and effort. Do some testing, and play with all the various branches on a development server. See what dialplan applications and functions exist, and how they work. Try to determine what kinds of things you need your phone system to do, and make sure the version you pick can do it. You can also make use of the various mailing lists and IRC chat rooms (asterisk-users mailing list, and #asterisk IRC channel) to ask specific questions if you’re not able to find an answer.

Hopefully this has made the release process a bit more clear. If you have any questions or comments, please feel free to leave a comment, and I’ll try to address all your issues as best I can.

Advertisements

Written by Leif Madsen

2009/06/06 at 10:42 am

Posted in Asterisk

Tagged with , ,

9 Responses

Subscribe to comments with RSS.

  1. Excellent article. Very clear and concise and the visual diagrams help to make the process easy to understand. Well done!

    Jaytee

    2009/06/06 at 10:55 am

  2. Thanks to jaytee, drmessano, kaldemar, and seanbright from #asterisk for helping by proof reading this article, and asking useful questions!

    Leif Madsen

    2009/06/06 at 10:57 am

  3. Excellent post!! This is a must-read for anyone for moving to 1.6.

    drmessano

    2009/06/06 at 10:59 am

  4. Thanks for this informal post.
    This will definitely help people with the versioning under 1.6.x.

    Don’t forget to +1 your Karma 😛

    grepmoo

    2009/06/06 at 1:07 pm

  5. Excellent post, Leif, really useful to understand how Asterisk is versioned at this moment, but I really don’t understand why it was changed the policy of versions in a moment that Asterisk is so strong and popular in worldwide (at least in Europe). I’m following you posts and really think that it can help a lot of people that are undecided about what version to use.

    Now, all of us have a lot of people, customer, partners that don’t know what version is better for a simple PBX, 1.6.0, 1.6.1, 1.6.2 or 1.4.X. All versions has a lot of bugs, regressions or broken features to be candidates for a production system.

    I think like you, “You have to use the Asterisk’s version that supports everything you need”. But I really think that Asterisk users prefer a stable version (inestables for the moment) with diferents features.

    This policy of versioning looks me confuses and it isn’t clear the useful to be able to get a software powerfully and easy to manage.

    I know that there is a thread on Asterisk-dev where it was debated but I don’t understand if this policy is really good for the project or it isn’t. Maybe the thing I don’t understand is what is the end for this change of policy.

    How I said, it is just my most honest opinion.

    Elio Rojano

    2009/06/28 at 12:35 pm

    • The first question, “Why was the versioning method changed?” boils down to this, “Waiting for 2-3 years to release a new version of Asterisk is unacceptable, especially when people want or need new features before that.”. The longer answer can come down to several things, but really there is just the one; you can’t wait for 2-3 years of development to release something, and then start trying to track down issues and bugs, and getting them all solves to try and stabilize the platform. It simply isn’t practical, and doesn’t make much sense.

      Your second question is, “I don’t know what version to use”. And as my post suggests, that isn’t a question that can be fairly answered. The main thing is what features do you need, or will you need in the future (lets say, within’ 12 months)? Whatever version contains those features is probably the version you need to run.

      As for your comment about all versions have a “lot of bugs”, I’m not of that opinion. There are many things I use in Asterisk every single day, and those things are rock solid. Some things perhaps are not as widely tested, and yes, you’re going to find issues. When I’ve run into this, I simple file an issue on http://issues.asterisk.org and make sure I follow through to getting a resolution. Once those issues are fixed, then I’m good. Plus Asterisk is an extremely complex piece of software — everyone is going to find a bug sooner or later (depending on what their doing of course). Perhaps you can elaborate on some of these issues you think are causing you to be unable to implement Asterisk?

      I don’t quite understand your comment by “Users need a stable version with different features”. I’m not of the opinion that Asterisk is inherently unstable.

      The policy is slightly confusing, but the purpose of it is to *make* it more manageable. Managing a project with as many feature contributions as Asterisk makes the new policy make a lot of sense. Have you been to the issue tracker lately, and just pulled up all the issues opened that are listed as “feature”? There are 80 of them in the Asterisk project alone, and that is a pretty good chunk when you consider there are 380 open issues in the Asterisk project. Releasing often is the OSS mantra, and I think moving to this model makes a lot more sense than waiting 2-3 years for a release.

      Thanks for your opinion! I personally think the new release policy is for the benefit of the project, for the community, and for the developers. Any of the arguments I’ve heard against the release policy then to boil down to people not either understanding why it is changing, or just that they don’t like change. I’ve not read anything yet that changes my thinking that this is a move for the best.

      Thanks!
      Leif.

      Leif Madsen

      2009/07/30 at 2:56 pm

  6. Hi ,

    Nice Post but I couldn’t understand one thing. If I am to use an application like JabberReceive , which is not available in my version , how can I get it in . I did access the svn and found .c files over there and I have a hunch I need to recompile my asterisk after downloading them.

    Usman

    2010/05/21 at 5:10 am

    • You use the version of Asterisk that the feature is first found in, otherwise you have to backport the changes which may or may not be trivial.

      Leif Madsen

      2010/05/21 at 7:50 am

  7. […] the new Asterisk versioning method (Originally posted at Leif Madsen’s blog.) Recently I have been seeing more and more questions about how Asterisk is being released now, and […]


Comments are closed.

%d bloggers like this: