Alright. I can hear you yelling at the screen right now. @Warcop is back again trying to get me to run a dot zero release. Yes. Here I am and I come with reasons and cookies.
Let’s bust a couple of myths.
Myth #1: Dot zero releases are evil and should be sent back to the hell that they came from.
I at least have a couple of readers who feel that way. I know you and here’s the response. The call manager development team is not evil and they’re not out to get you. The code base that is call manager is very mature and portions of the call control code hasn’t changed in years. The team that works on dot zero releases is probably the same team that works on all the other releases. So I ask you a question in return. Why do you trust the person coding service updates more than the person coding the dot zero?
Myth #2: Call Manager dot zero releases should be considered a beta.
This myth is in an echo chamber outside of Cisco and within Cisco. Call manager releases come on schedule and if you notice there’s a predictable cadence. A dot zero release is what I consider a fork of an existing .5 release. If you browse the bug tool (yes I do this for fun) for any release you’ll likely notice fixes are published for a .5 and .0 release. So both release trains are getting the same bug fixes where applicable. So why do you trust 11.5SU5 more than 12.0SU1.
So if they contain some of the same bug fixes does that mean the code is the same? Don’t leave now! I have proof! The recent work on the Apple Push Notification service has required some fixes to the call manager service. So it’s no surprise that the APNS COP file to patch call manager applies to BOTH 11.5.1(SU3) and 12.0(1). The file that’s in this patch is the call manager binary and if it applies to both versions.. ZING! If you’ve applied CSCvf57440 to 11.5(su5) you’re running the same call manager binary as 12.0(1). Saying that a dot zero release is a beta is not accurate. A dot zero release is not described as beta software on the website or release notes.
There’s a wealth of reasons why you should be moving to version 12. I’m liking the security updates the most since that is top of mind with nearly everyone. Instead of listing all the features here the datasheet link is: https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-manager-callmanager/datasheet-c78-739475.html
The CCIE Collaboration lab is also being upgraded to Communications Manger version 12. If it’s good enough for the lab it should be good enough for you!
There are production clusters in the world running version 12 and they’re humming right along. Let’s face the reality that software updates are being released faster than most of us can absorb. So why not change the echo chamber to “Why would you not run the latest code?”
Here’s a quote I remember and reference often: “Updates are evil. Updates are only OK when I don’t read the release notes and click install.” — @swiftonsecurity
Bring the feedback @Warcop on Twitter
Foggy Bytes 
Very interesting post. I completely agree with all you said about dot-zero releases not being evil from a code/bug perspective. By all means, for a customer who would need any feature only available with CUCM 12.0, I would install it in production for them in a heartbeat.
This being said, your post overlooks what is, in my opinion, the single most important reason for going with a dot-five release rather than a dot-zero: longevity. The long live release for any CUCM train has always been the dot-five release, with the dot-zero release starting its End-of-Life cycle much faster than its dot-five counterpart. Many customers, especially in large contact center environments, will avoid CUCM upgrades like the plague, mostly due to the complicated compatibility matrix between all other apps integrated to it. Going with a dot-five release brings them peace of mind from a supportability perspective.
Cheers!
~ Eric
Heard this argument for 9.0, 10.0 and 11.0.
Avoided all of them.
Laughed at poor sods who’ve done rollbacks for things like DTMF not working with UCCX, cluster service crashes, etc.
Not a myth, as soon as you work on non-trivially sized clusters.