If you fix drum maps in templates, it does not take a genius to work out that drum maps should be tested everywhere in case of regression issues, esp under saving conditions. From the look of it they don't do automated testing, but that's hearsay. I think per month we are to expect 3 or 4 visible regression bugs based on past history for Platinum. If we knew that these issues were quickly patched up (say a week or two later), or if we had a monthly stable release alongside a new feature release (we could choose) it might not be such a big deal.

Ultimately this is going to fall back onto voiced concerns when the membership model was announced if this trend continues. At the point of each member's renewal, if a damning bug is introduced in that last release, the user will be faced with paying for a bug fix or rolling back to the "best known version." I agree with the OP in that new content rates significantly lower than work flow enhancements and impeccable stability for me.
 
The "hitting a moving target" is most obtrusive from my perspective, as trying to keep track of things creates more undue overhead than necessary. In fact, it should not even be required.
 
Even more disconcerting to me is a recent series of crashes... the VSTi vendor took this VERY seriously (it was a crash after all) and emailed me twice in 24 hours. As someone who takes "field failures" as the #1 tarnish to one's reputation, the response in these forums as of late is often upsetting to see. This is even worse when someone does not have the bandwidth to read/report things, and what is in their lap is "all there is."

mettelus
This is even worse when someone does not have the bandwidth to read/report things, and what is in their lap is "all there is."

I've given up reporting altogether.

Vastman, this is a misrepresentation of how software development works. It is common practice to have a phase for making changes for new features and bug fixes, followed by a phase of testing and fixing to ensure stability of the release. Having a fixed time for releases inevitably bears the risk of releasing the software before enough time was spent for stability testing. (BTW lfm, this kind of working on different branches is one of the main sources of bugs, because it prevents testing the full system in a stable state.)

Also, if it was the scheme that 40 bugs are fixed each month and only 2 bugs are generated, the software should become almost bug-free with time. That's not what happens in reality. Most software (and of course Sonar is far from being the worst in this regard) is released without doing enough testing. Instead, customers who pay for the software have to do the job of testing and reporting bugs, and they are even told that it would be good customer support to fix the reported bugs. It would be better customer support to release software that has been tested thoroughly to have no bugs, at least no obvious bugs that become apparent just by using basic functionality of the software.

If drum maps no longer work in saved projects, then I don't see what benefit it is that other problems with drum maps were fixed. I can no longer use them. And I wonder how testing is done, if all you have to do is to load a project with a drum map and hit play to see it's no longer working.

Yes, I reverted back to the D release (mainly because of the new problem with controller lanes). But it takes my time to install the software, to find bugs, to decide if the new bugs are worse than the old fixed bugs, and to revert to the previous version. And both new bugs, I found just by loading a project and trying to do a small standard edit.

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.

Yes this is built into our system. If we encounter a serious regression that has no simple workaround we do release a point release earlier than a months release cycle as we have done earlier. If its something that affects you that much so that you cannot work, you can always roll back in a couple of minutes! That's how this system is supposed to work. SONAR is a complex piece of software and there are hundreds or thousands of use cases of it so no matter how much testing is done by our team there is always going to be potential for something to change that nobody notices. 
 
We take monthly releases very seriously and they are treated exactly like the annual releases with a full (though compressed) release cycle and every fix is regression tested. We're sorry that this one bug that impedes workflow slipped in - we'll do our best to fix it sooner than later.

It is NOT a "subscription" model!!

Noel Borthwick [Cakewalk]
 
Yes this is built into our system. If we encounter a serious regression that has no simple workaround we do release a point release earlier than a months release cycle as we have done earlier. 

So far that has happened once over registration issues? (Correct me if I'm wrong, you have the facts).
It depends what you class as serious, one persons major bug can be another persons trivial or irrelevant issue. If I don't use drum maps then I don't care. If we knew that a stability point release for regression issues was a regular occurrence then the moving target stabilizes. I'd prefer not to deal with workarounds.

Hey Noel, for the record, I am a big fan of the monthly release format, I like it a lot. It seems as demonstrated when you released that 'b' release in Briantree (I think Braintree or an earlier one) that you guys are showing your proactiviness when a biggie hits. The point I was trying to make, was that it would be good to see this in general, not just on 'biggies'. At the moment it seems like 40 steps forward and 3 steps back with every release. But if a step back happens to be a pain in the arse,  it can feel like 20 steps back. Bugs on a way are pretty personal, some users put up with, some it breaks them.
 
I'm not in the OP camp, but I see his point. if a b release was more general, rather than applied to extreme cases, it would be reassuring. Especially when I am on month 12 and an issue is introduced along with a feature. I will either have to put up, or roll back and loose the feature. That's a nasty taste when you come asking for another years commitment. 

ralf
(BTW lfm, this kind of working on different branches is one of the main sources of bugs, because it prevents testing the full system in a stable state.)

What is the alternative - one developer on Sonar - yes,that would speed things up...
 
Somebody responsible for system as such must direct who does what, and what needs to be tested fiddling with certain parts of code.
 

It would be better customer support to release software that has been tested thoroughly to have no bugs, at least no obvious bugs that become apparent just by using basic functionality of the software.

It's always obvious to the user - that their particular setup and way of working - is everybody's way.
- didn't you test this at all?
In daws where the biggest part of setup would be 3rd party plugins - so many sources for problems.
 
Just look at jBridge and how different options were added with each release, tells a little if different it can be - bridging different plugins. Lot of options how to update guy, normal or sparse and many other things etc.
 
The total for me - it's a miracle that it works so well.
 
I had my portion of rants over the years with my customers when I had my business. Things that just didn't happend on my system but with user system. An array wasn't fully initialized and caused crash at end user - but not on my system and the values that just happend to be there on my system stack. Other times certain parts of gui was not visible for customer - turned out to be a bug in his graphics drivers, and lines drawn from right to left never showed up.
 
All this hardware and software working together - it's a miracle to me...nothing less...

BENTWe just want it to work so we can make music

for us as end users, this is all that matters; for cakewalk as a business, this is only a part of the story... finding the right threshold is the key...