The Evolution of Asterisk (or: How We Arrived at Asterisk 10)

By Kevin P. Fleming

We are fast approaching the seven-year anniversary of the release of Asterisk 1.0.0, which occurred at the first AstriCon in September, 2004. If you look back a little further, there were various “0.x” releases made as early as December of 1999… my, how time has flown!

We’ve had quite a few ‘major’ releases of Asterisk since then, including 1.2, 1.4, and most recently, 1.8. Each of these releases has included significant changes, and sometimes architecture-improving changes. Each of them has also included substantial new functionality for Asterisk users. Along the way, we’ve been asked by many people in the community when we are going to start working on (or release) “Asterisk 2.0.” Typically, we’ve responded by saying that will not happen until we can really justify such a significant change in the version number. Many open source projects have gone through similar progressions, and quite a number of them have in fact undergone complete (or nearly complete) rewrites resulting in new ‘major’ versions.

The Asterisk project, however, has tried to avoid that level of disruption to its users. Instead we’ve focused on attempting to provide as much backwards compatibility between major releases as we could. As a result, each time we’ve released a new, major version, the decision has been made that “No, this isn’t Asterisk 2.0,” and we’ve continued with the version numbering scheme that Mark Spencer started all those years ago.

Over the past few months though, as we’ve approached the first beta release of the next major version of Asterisk, we’ve been having a somewhat unexpected conversation: about just how different this release is going to be from the releases that most users in the community are using on their production Asterisk systems (primarily Asterisk 1.4, although there are still a lot of 1.2 users as well).

In fact, even though it’s been an evolutionary process, not a revolutionary one, the next major Asterisk release really will be substantially different from Asterisk 1.4 in some very noticeable ways: wideband conferencing support, basic video conferencing support, support for a number of additional VoIP technologies, full-fledged FAX support, and many others.

That has raised the question: Is this Asterisk 2.0? If not, will there ever be an Asterisk 2.0? After quite a lot of discussion, we came to the conclusion that this is not Asterisk 2.0, but that it’s also quite unlikely that there ever will be such a release; it wouldn’t be in the community’s best interests to release something that is fundamentally different (and not compatible) but still call it ‘Asterisk.’  That then leaves the question we’ve been asked by many people: If there’s never going to be an Asterisk 2.0, why continue to call these releases “1.x”? What does the “1” mean, if it’s never going to change?

The conclusion that we’ve reached, and that we hope you’ll agree with, is that Asterisk is always going to be Asterisk, and that you don’t need a “1.” prefix on the version number to be able to identify it. So, starting with the next major release, we’re going to drop the “1.” completely. The next major release, which was going to be Asterisk 1.10, will now be just “Asterisk 10” and subsequent major releases will be “Asterisk 11”, “Asterisk 12”, and so forth.

We’ll continue with our plan to have both standard and long-term support releases of Asterisk, and we’ll update the Asterisk Project Wiki with this information as soon as the first Asterisk 10 beta goes out. In fact, this should occur very soon.

As always, thanks to everyone for their continued support of Asterisk. That especially includes the developer community, the people that find and report issues, the people that help test patches and the people that devote their time to answering questions on IRC channels, the mailing lists and the forums.  We hope to see everyone trying out the forthcoming beta, and we look forward to seeing you all at AstriCon 2011!

Related Posts

There Are 3 Comments

  • Lyle says:

    Meh…semantics. Next year is it Asterisk 2012, how about Asterisk XP! 🙂


  • Baylink says:

    So… what you’re saying here is that you don’t want to encumber yourselves and your users with the API breaking implications of a major-revision bump…

    you’d rather break the semantics of what a major revision bump *means*, by making what people *assume* carries that implication — the first component of a version number — be changable without such breakage.

    In turn, that deprives you of *any way at all ever* to actually *signal* such a bump; you now *cannot have* a 2.0, should you ever need to signal API backwards-incompatibility, since you’ve sliced off that first number.

    Do I have this right, Kevin?

    Version numbering has evolved over 30 years to be what it is, and work how it works, for Very Good Reasons. This didn’t work out all that well for Sun (with Java), and we know what happened to SCO (who confused a *lot* of people by selling the SVr3.2 based Openserver as “4.0”… because it was ‘SVr3.2v4.0′)… and I can’t say I think it’s going to work out well here, either.

    Much more important to me, though, is what it says about the project management. Not understanding the contract that’s implicit in version numbering, and the increments thereof, falls — for me — into the same category as Tom Peters’ 30 year old admonition to airlines: if you can’t be bothered to clean up the coffee stains on your tray-tables, how in *hell* can the passengers trust you to have been doing your engine maintenance properly.

    This stuff really actually matters, and has real-world implications; it’s not just chrome. I promise.

  • Asterisk 10.0.0-beta2 Now Available | Latest News About Asterisk | says:

    […] With the release of the Asterisk 10 branch, the preceding ’1.’ has been removed from the version number per the blog post available at… […]

Add to the Discussion

Your email address will not be published. Required fields are marked *