2.4 Beta Program Launch - Early Holiday Gift to You

<?php global $user; $custom_field = 'user='.$user->uid.""; ?>

We’re excited to bring you the kickoff of the 2.4 beta program in time for all that down time you are preparing for during the holidays! Since donations have been down for a while, I have not had to take time bookkeeping so I’ve had time to crank out a lot of good stuff for 2.4. However, with the Holidays coming up, maybe no donations isn’t such a good thing, hint, hint…



The theme of 2.4 has been a focus on validation and integrity checking to help you catch errors like IVRs with destinations that no longer exist, or overlapping extension number (e.g. a user and a conference set to the same extension). These are hard to find errors and unfortunately it is more likely that your customer finds them then you! In addition here are plenty of other new features, some new modules and other functionality to make this release attractive. There's too much to list but I'll highlight the big changes below. You can take a look at the 2.4 Milestone on the development site for a list of all the enhancements as well as links to bugs, feature requests and other tickets that have made up this release.

Here is a run-down of Changes:

  • Extension and Destination Registry to provide integrity checking for configuration setup and block/detect various configuration errors.
  • Custom Apps Module to support registration of custom dialplan extensions and destinations so that they can be included in system integrity checks.
  • Changes to Zap Channel Routing - now treated just like other inbound routes by assigning DIDs to Zap channels (which means you can route on CIDs now).
  • Many fixes and changes to Device and User Mode to properly support adhoc devices and hints.
  • Paging & Intercom improvements, feature enhancements, support for more and custom phones.
  • Addition of Voice Mail Blast module to support group voicemail announcements.
  • Addition of Language Module to support language changes as part of module linking as well as language attribute to user extensions.
  • Support for "call confirmation" with hunt strategy in Ring Groups and Follow Me.

How to install the release?

During the initial testing phase you will have to download and use the standard "tarball" upgrade process to get going, which can be found here:

Upgrade Process to 2.4 Beta

We will provide an upgrade ability through the Online Module Repository to go from 2.3 to 2.4 once we have received enough testing as part of the Beta program. We do not want to provide that ability too early, as we do not want you accidentally upgrading production systems by choosing this option in the Repository.

How can you help?

Well first and most important, did I mention that donate button above or on the left? In order to continue the evolution of this great product, we need your financial support - we have thousands of our donated hours in addition to the real infrastructure costs for this Site and the Online Repository.

Next, testing. Most of the core dialplan and critical components have remained unchanged or have been carefully scrutinized. We expect very high stability going to this release. However there are a few areas that have undergone some changes and explicit testing of these areas will be valuable. These include:

  • Queues. The changes here are because we have ported the Queues module to a more modern underlying infrastructure as it was amongst a few of the old modules that had not been updated since the AMP days. The code is fundamentally the same, but there is a big conversion process when you upgrade and we would like careful eyes to scrutinize that Queues are still configured and acting like they were previously.
  • Zap Channel Routing. Existing Zap channel routes will be converted to a Zap Channel DID entry in the form of zapchanNN and then a corresponding route for that DID. You should confirm that the conversion continues to operate, and then consider changing the DID information to proper DIDs and testing the new abilities such as CID routing with Zap Channel DIDs.
  • Extension and Destination Registries. All modules should be properly implemented to block duplicate extension numbers and generate notifications if there are problem destinations. You should test out this mechanism by trying to create various errors and confirm they are blocked and/or notifications are generated upon applying a configuration. You should also convert your custom destinations to entries in the new Custom Apps module.
  • Bug fixes! Either help by providing patches, or if you are a developer and would like to get more involved contact us so we can work with you to get involved. Providing bug fixes and patches are a great way to show your work towards getting SVN access.

We are excited about the new capabilities that are in this release and look forward to running it through a thorough beta test cycle so we can get the release out for general consumption.

Thanks, and Happy Holidays!

Philippe - On behalf of the FreePBX Team

Kudos to the entire dev team on the 2.4 beta release. I’ve been running this in a closely monitored production environment now for 3 days without any major problems. However, you must realize as with any BETA launch there will be minor flaws, after all thats why it’s beta, but none that have been system critical. The evolution of this project over the past year has been well above expectations if you take into consideration of the project change over to the new lead developer.

Thanks for the early Christmas Present.

Thanks for your continued work in making freePBX even more awesome!!!

Any guess at this point when the online module update to 2.4 will be available?

the earliest we will make an online update available from 2.3 to 2.4 is rc1 or rc2. At this point, although we feel the current beta release is extremely stable and could likely be an rc candidate or even a final release, we have not had adequate test coverage. One of our bigger installed bases has not yet provided a beta upgrade package to their user base and we would like to see that happen before moving into rc.
We choose this because we don’t want production users to accidentally upgrade to a beta because of the ease of doing such in the online system.

The evolution of this project over the past year has been well above expectations if you take into consideration of the project change over to the new lead developer.

link removed do to potential spam abuse