Kylotan
Okay, we're 5 mini-versions in to the new model, and I'm concerned. Yes, we've seen bug fixes each time, some great ones. But we're also seeing new bugs being shipped each time.
 
3) Everett has broken Drum Maps again - either losing the output assignment for some people, or just not playing anything back at all for me. http://forum.cakewalk.com...rum-maps-m3230072.aspx
4) Slip-editing linked clips seems to break (although maybe this is an old bug, since it seems familiar) http://forum.cakewalk.com/Slip-edit-moving-things-wrongly-m3230458.aspx

 
Great!!! I was going to update to Everett tonight but now will not, maybe "NOT EVER" this is the very thing that concerned me about the new release system. One has to question if it is a improvement or a step backwards. Yes I know I can roll back, but I don't have time to waste. At least with the old system I could wait months before updating to the latest release to make sure the features that are critical for my personal needs are stable. Now it's like Ground Hog Day the cycle resets to new release and uncertainness every month.   
 
 

Kylotan
So right now, each month I get a bunch of new content (none of which I use, to be frank) and a 50% chance of a program-breaking bug that may not get fixed for another month. It doesn't inspire a lot of confidence and today the first chance I got at writing music for quite some time has been completely ruined by Everett not being able to play my drum VSTi. This is not what I want from a DAW and I hope that Cakewalk are going to reflect on their QA process and make sure they're not just shipping new bugs each month (and then getting the credit for fixing them later).

+ 1000

Noel Borthwick [Cakewalk]
We will look into this issue. I'm not convinced yet that it was indeed introduced in Everett however.

 
It was introduced in Everett. We were using drum maps perfectly fine a few days ago, and now we can't.
 

There were at least 2 drum map issues including crashes that *were* fixed in Everett.

 
Doesn't matter if we can't use them at all.
 
 

Overall in Everett we fixed 40 user reported bugs including at least another 30 internally reported issues that we do not list in the bug fixes. I think that's a pretty good ratio of issues resolved in a month by any standards. Its always possible that a new issue may present itself - its the nature of software development.

 
New issues tend to present themselves when you add new features or functionality. If you concentrate on bug fixes, this is less likely. Software is tricky, but it's not impossible to push a release that has no extra bugs.
 

From an engineering point of view there is no question that the new model has way more reliability and a faster turnaround as well.

Sadly I am not an engineer on your project so I don't see these benefits - just the different bugs every month.

Vastman
Kylotan... Oy!  I think Noel said it eloquently. And tweaking little niggles every month rather than a yearly explosion of joy and anger is far superior.

 
With a yearly release, there is more time to test new features and make sure things are going well, but more importantly, more pressure to make sure it works. Now, there's a real feeling of "ship it, and if it's broken, just fix it for next month".
 

Your logic is just shortsighted.  If several bugs relating to the Drum Maps have been solved, it's way better than waiting another year.

WE CURRENTLY CANNOT USE THE DRUM MAPS AT ALL. That makes the software almost entirely useless to me, and worse than every other release of Sonar I can recall in all the time I've used it.

mudgel
To those who are worried about monthly updates and stability and testing whatever.

You could always stay with the version you're happy with. Say X3e and upgrade when you feel the feature set and stability are right for you. Also you don't have to update every month. It's a choice.

My point is that the stability does not seem to be improving at all. When X3 came out, you could wait until X3e and that was almost undeniably more robust than X3. Now, it's a churning situation of bugs coming in and bugs going out, with it being almost pot-luck as to whether any monthly release is better or worse than the ones before it (new content aside).

KPerry
And do remember that if a problem in a new version does bite you, at least it's painless to roll back a version: Cakewalk haven't made you use the latest downloaded (which is much appreciated, I'm sure, for cases like yours).

Yeah, I could roll back... and get back the bugs that were freshly introduced for Dorchester. It's not great.

Well said Kylotan
 
With respect Nole, not many end users are overly concerned about the eloquence of the code. We just want it to work so we can make music

Kylotan

mudgel
To those who are worried about monthly updates and stability and testing whatever.

You could always stay with the version you're happy with. Say X3e and upgrade when you feel the feature set and stability are right for you. Also you don't have to update every month. It's a choice.

My point is that the stability does not seem to be improving at all. When X3 came out, you could wait until X3e and that was almost undeniably more robust than X3. Now, it's a churning situation of bugs coming in and bugs going out, with it being almost pot-luck as to whether any monthly release is better or worse than the ones before it (new content aside).

I can only say that I've found every version to be slightly smoother than the one before. At least it feels that way. The bugs I've encountered I've been able to work around. One of Sonar's strengths is that it presents several ways to do a particular thing. I only had one issue not directly Sonar related but the Cakewalk store backend and that's behind us now.
Generally I think I'm a heavy Sonar user with lots of tracks, routing, fx plugins, VSTIs. I do lots of experimenting so it's not like my workflow insulates me from Sonar's bugs. BUT no show stoppers and that's the main thing.

I don't blame the monthly updates at all for these inconveniences mentioned in OP.
It's more to do with how developers work as a team.
 
Checking out a class for whatever versioning system does not make the changes come in next release unless ready and tested and checked in again.
 
And if this code is not fully tested, it can be excluded by inserting switches in code - governed when to activate, when it's actually tested and ready for release.
 
And devs need to syncronize if they are working on the same class - usually handled when a checkin is made, by merging code. But testing of that class really need to be tested by both working on that code before release. If not doing the latter - you might get current result that new bugs are introduced by fixes.
 
The possible flaw in events regarding this - does not improve by just increasing intervals for release.
But maybe cut out some fixes for a release until fully tested - that a fix does not backfire.
Use code switches that are not removed until fully tested - so they don't interfere with other fixes.
Somebody with the overall knowledge of Sonar as a system need to govern this - can this fix alter behavior in other areas and inflict on that.
 
How Cakewalk is taking care of CWBR and categorising these, finding mutual cause of problems etc - and putting on todo list - and also fixing problems - is an internal problem at Cakewalk not to do with release intervals, as I see it.
 
Cakewalk improved a lot the last five years - and there is no doubt they are always working on to improve.
And maybe the heat is on to make a certain length of a fix list each month.
But this monthly release model is rather new - and is sure they will alter how they do things to improve.
 
I absolutely love this new model of working and releasing. I'm most likely to benefit not having to experience many bugs because of it.
 
I mean each bug usually introduce some hours of narrowing down and finding a workaround  and multiply that by each fix made each month and then multiply by users of Sonar - that is many manhours saved.

What if was a possible 'b' release, there was one in Braintree, that dealt with an introduced issue. So any new bugs that are picked up are addressed before the new months release. So if 3 bugs are found that are new monthly release, these are treated as a priority and a update just for these is provided. If a change has revealed a bigger issue, then maybe this on of the three is left until the next month, but the other two are sorted. Making each release more rubust.

Kamikaze
What if was a possible 'b' release, there was one in Braintree, that dealt with an introduced issue. So any new bugs that are picked up are addressed before the new months release. So if 3 bugs are found that are new monthly release, these are treated as a priority and a update just for these is provided. If a change has revealed a bigger issue, then maybe this on of the three is left until the next month, but the other two are sorted. Making each release more rubust.

Really good idea....