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.

I think it's great having the monthly updates. I've only ever had a problem once, and the ability to roll back updates meant I could immediately get rid of the problem. Seems to me like things are working fine.
 
I also like the fact that monthly updates mean they don't need to have a big headline-hitting update every time. This month's update is a good example of one that contains nothing particularly big, but makes a bunch of small but extremely helpful refinements.

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.

Yep, I like the CURRENT model for releases/updates.  I get that a fixed rigid schedule can lead to introducing bugs if the bakers aren't careful, however, it's better than NO schedule.  I found out a long time ago that we have to set deadlines to help us focus our energies on the tasks at hand.  Otherwise, things have a way of slipping past us and when we finally do get it done it's not always good anyway.
 
Tight schedules = tight focus

+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.   

The update model is inextricably bound to sales model, which creates it's own issues of "something" monthly. The glaring issue with rollback is that issues do not close next cycle, so the choice must be made of the least issues (which isn't published). This also creates hurdles for support because of the differences between versions, so much is left to "tribal knowledge." When those folks (ones heavy in the history/detail of the program) are no longer available, things often degrade or collapse completely.

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

The update model of Cakewalk is well thought imo.
Every user has the chance to update monthly or whenever  the time is right.
The CC and the possibility to update offline give several options to
all kinds of update-needs one can think of.
I personally don´t  need monthly updates,
but I like the modus and the range which the bakers are offering.
 

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

^^