Anthony, I would be interested to know how you and the other Freeswitch developers go about deploying new 'versions' of the code. Traditionally Linux uses various flavours of package management, such as RPM and APT that takes an upstream source tarball, combines it with patches and any other vendor supplies changes and then makes a package that can be installed on multiple servers. At Infinity Tracking we have been using Freeswitch in production for over 6 months now and it has been extremely reliable. We run several servers in a cluster, so it is important that we can manage code deployments effectively. We use RPM and Puppet to ensure consistent package versions. With every other piece of software in the stack we use; MySQL, PHP, Apache, Nginx, Memcached, Redis to name a few they are released as tarballs or at least versioned tags in git/svn. This enables us to pull down either a tarball or extract a specific tag version and from there build a package with a version number. With Freeswitch we have to 'git pull' the latest head, and then increment our build number, e.g. 1.0.7-12, however our version number of the package is internal to us, and so is of no use to other people for reporting bugs against. I understand your concerns about the rate of development and how you don't want to get people stuck on older versions, and we don't expect a tagged version to instantly deployable without internal testing ourselves, just like git head wouldn't be. I was wondering is there any possibility of having something like a 'nightly' build version that is tagged in git that people could use as a common reference point? Thanks Tom