bitflipper
I very much like the frequent updates.
 
What I don't like, though, is scheduled frequent updates. That puts pressure on the developers to get an update out within a predetermined timeframe that does not take into account the realities or difficulties with whatever changes are being made.
 
Some fixes are quick, easy and easily testable. Others require sitting around a conference table for days, discussing basic architectural changes that have the potential to cause unexpected problems. My advice would be to get those quick fixes out quickly, but if there aren't any of those in a particular month, then take as long as needed.

We have different development branches precreated for the future, and we often have more long term features in development that are being developed in a future branch. When a feature is deemed good enough for release its put into the main branch. This works well for the most part except for unexpected or unseen problems. But thats why we also have an early access program to help expose them.

This is my own development model, too. I hate knowing I've loosed a bug into the world, so my main branch is rarely more than a day or two from a releasable state. That means I am able to turn around a bug fix very quickly, often on the same day it's reported if necessary.
 
Long-term features stay hidden or uncompiled until they're ready to debut. I have no release schedule, no pre-announced release dates. In fact I have no mandate to do anything at all if everything's running smoothly. My users, many of whom have been with me since the early 90's, have come to expect that they'll get fixes quickly and major enhancements only when they're ready. I'm sure Cakewalk feels the same way, and that that is the basis for the frequent release model they've adopted.
 
Of course, I have an advantage over Cakewalk in that I am the sole developer these days. That means there are no design meetings except the ones that take place in my head. I'd like to say that limits the number of heated arguments, but it doesn't.

+1 for the monthly schedule.  As most of the users have figured out, having a fixed time for release does not mean "new" features.  Having bugs squashed or just tweaking a task is still included in the cycle.  And that is just fine with me.   

bitflipper
This is my own development model, too. I hate knowing I've loosed a bug into the world, so my main branch is rarely more than a day or two from a releasable state. That means I am able to turn around a bug fix very quickly, often on the same day it's reported if necessary.
 
Long-term features stay hidden or uncompiled until they're ready to debut. I have no release schedule, no pre-announced release dates. In fact I have no mandate to do anything at all if everything's running smoothly. My users, many of whom have been with me since the early 90's, have come to expect that they'll get fixes quickly and major enhancements only when they're ready. I'm sure Cakewalk feels the same way, and that that is the basis for the frequent release model they've adopted.
 
Of course, I have an advantage over Cakewalk in that I am the sole developer these days. That means there are no design meetings except the ones that take place in my head. I'd like to say that limits the number of heated arguments, but it doesn't.

What is the software that you develop? Sounds interesting

http://www.commitstrip.com/en/2017/03/10/anyone-can-be-wrong-sometimes
 

I like the monthly update though they have always come in the 20 something dates of the month... They seem to have fallen behind a bit...  I'm not complying... I just want something free.... lol 
Not free advise on my post here...;)
 
Come to think of it I just got an LP EQ from Cakewalk that rules the world! I think it may have been there before but it never worked for me but now!!!
 
carry on.. :)