Here's my second to last on the subject:
 
Arguing about the validity of Cakewalk's approach to development and testing without a deep, inside view of what they're doing and how they're do it is pointless.
 
The cleanest possible way to get the concerns about stability across is to point out the problems you're having with recipes to reproduce.
 
Once that is done, it is up to Cakewalk provide fixes, do the tally and make adjustments as appropriate.
 
There are a lot of ridiculous assumptions and accusations in these threads, the most glaring (IMO) being the assumption that things are being released according to a calendar without regard for their readiness.
 
Another is that "we" somehow know more about the best way for them to run their business - with the same lack of inside information.
 
 

Doktor Avalanche

Anderton
So if there's some major bug one month that kills workflow for you, roll back or don't install and wait a month until it's fixed. 

Yup you decide which regression bugs you want to live with, it's a feature.

It's an improvement compared to having a year's worth of bugs rolled into a yearly release, at which point you have to either live with all of them, or none of them by not using the new version. Yearly releases had regression bugs too.

Doktor Avalanche

BobF
If you wait for the smoke to clear before adopting any one of the releases along the way, you will have taken a positive step toward minimizing risk.

Yup but you are missing the point, the smoke clears for one issue, and then the fire starts somewhere else. Without a regular stabilization release for regression issues then you are left with choosing the fire you want to cope with I guess (the fire that burns down your next door neighbours flat, rather than your own)....

If I install the update from 6 months ago there should be no new fires.  Jeez ...

BobF
There are a lot of ridiculous assumptions and accusations in these threads, the most glaring (IMO) being the assumption that things are being released according to a calendar without regard for their readiness.

If features had been released according to the calendar, you would have had Drum Replacer in February - that's when it was scheduled to be introduced. It was delayed until it was ready. I think the reaction to it shows the delay was justified.
 
What people don't seem to understand is that development is always ongoing, on multiple parallel tracks. All the tracks undergo testing. When the testing is considered complete for one track, it's ready to go and eligible for release.
 
There have been numerous complaints that Cakewalk is not forthcoming about telling which new features will be introduced, and when. This is done specifically because features are NOT released according to a calendar schedule.

BobF
Does anybody really believe that development wasn't continuous under the previous model.

This is absolutely true, but the flip side is that (under the previous model) decisions are made to promote stability in "what exists" with harder work to be updated/included at a later point. This is why versioning is locked.
 
In fact, the monthly updates now are discreet versions (on a monthly basis rather than yearly - essentially 20 working days per release); but seemingly with more intent to stuff us like a Thanksgiving turkey with "fluff," than to address what users have requested for years. Now that the "assembly line" has been set in motion, I do not believe that adequate resources are left to perfect work flow requests (and there are a lot). Even in marketing videos, the "content" of what people can assume about something is minimal (I had to hide the CW instruments forum because of the backlash to Rap Pro). I certainly am not excited to watch the train truck down the tracks with "fluff FIRST" being the #1 priority for a "release." Give the users something... anything... and they will be happy?
 
Unfortunately, the new membership model essentially mandates a monthly update, even though many early on said they would be fine with things less frequent as long as it was functional and stable.
 
 

ralf
The alternative is to have a strict separation between development and testing phase. During the testing phase, no new features or other code is introduced, but all branches are put together and changes are made only for bug fixes. Testing and fixing are repeated until the system is stable. But this kind of testing requires more time for a complex systems like Sonar than you can spend each month. So, the monthly release schedule is part of the problem.

I am totally aware that interdependencies with 3rd party software and hardware may cause problems that are hard to find by testing for the developer. But we are speaking of bugs in the basic functionality of Sonar. Using PRV with multiple tracks or using drum maps are standard use cases.
 
(Edited to add that this is a reply to lfm.)

Been there - done that, kind of.
Every little change in code - should go through and test every aspect of the product.
And it's still no good without beta testing.
 
You must make a fair estimation what might be affected by a change.
Introducing drum maps into track templates - well, that means you should test everything about drum maps.
Clear mistake on this estimation that they don't open properly from projects anymore.
 
To be fair - shouldn't we separate "being stable" from "all is working as intended" also.
- Is there anything reported that go under "not stable"?
 
It's rather serious if new bugs puts your work to a halt - I can understand that fully.
So your disappointment is valid.
What were they working on that they did not test if multiple tracks editing worked as intended?
I will have a look at your link unless this is confirmed already.
 
But don't think all development should be put to a halt either - because your process for getting things released would mean that, more or less.
 
I think Kamikaze idea to do nothing until newly added bugs is first on todo list and fixed - is the way to go.
Maybe an intermediate fix even between regular periods - showing extra concern about the matter.
- Nobody leave the building until this is fixed, kindof. 
 
There is a risk of human nature that knowing there is a new release soon, one does not pay enough attention before a release. But now brought to Cakewalk's attention - this might be improved in the coming releases.

Doktor Avalanche
Yup but you are missing the point, the smoke clears for one issue, and then the fire starts somewhere else.

This happened with yearly releases, too, except all the smoke cleared for some bugs and all the fires started somewhere else simultaneously. The main difference is that the monthly release allows for quick fixes, more regularly.
 
I don't think anything is naive enough to argue the new model is flawless. But it would be equally naive to argue the old model was flawless, or for that matter, ANY software sales and update model is flawless. Again, it's all about tradeoffs. If you look back objectively at X3's post-release trajectory and Platinum's post-release trajectory, I think it's obvious which gave more substantive progress in a shorter period of time.

Anderton
 
What people don't seem to understand is that development is always ongoing, on multiple parallel tracks. All the tracks undergo testing. When the testing is considered complete for one track, it's ready to go and eligible for release.

 
And yet drum maps weren't regression tested after fixing a drum map template issue. It wasn't exactly obscure to say the least.
 
Here's a scenario to consider....

Last release there were issues with track templates which got fixed in this release (haven't tested but feedback in problem reports forum looks good). This release issues with drum maps in templates were fixed which broke projects.
So I'm left with a choice as to which I have to cope with (or roll back further and cope with another issue).

If the bakers concentrated on one specific area for improving work flow and bug fixing, then I will know what release to avoid. For instance if one single release fixed the signal path for drum maps, fixed drum maps in Sonar templates, and launched an improved drum map UI, I know that release is probably worth avoiding for that month because there will be regression issues, but at least it will be probably be all over and done the next month. If on the other hand it is drip fed over a number of months then I stand to get disruption. Right now this is the second clear regression issue with drum maps (the other one is when we though the signal path was fixed, but it turned out to be a red herring).

I don't know what regression bugs are. Its a term that is very new to me. I have some vague understanding about what regression testing is. I wont use these terms in a post because I don't know enough about them to be confident that I am talking about something I know well enough to say something about them. I can say I have never done regression testing. At least not knowingly.
 
Its possible that some members know what these things are. I suspect that most don't. 
 
It would help greatly if we all stopped using terms we know nothing about in trying to make a point when all that really happens with their use is confusion and making things unclear. If however when a term is introduced explaining it in detail might make its use productive. 
 
 
 
 

Anderton
 

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.

 
You can do that now. This system is far more flexible in terms of giving choices as to how customers can buy, install, and use their software.

 
No, I cannot, because the releases are not getting more stable.
 

The real question is whether the new model has fewer tradeoffs or more tradeoffs than the older one. I think there is  no question that the new model has fewer tradeoffs because YOU choose when to update, and can update only to the extent you want if there's a bug that's essential to your workflow.

In the past, I could buy a version of Sonar with the features I wanted, and know that it would only get more stable as patches were released. That's been the case since the Pro Audio days. Now, I can buy a version of Sonar with the features I want, and I just have to hope that the patch releases fix more than they break.