Noel Borthwick [Cakewalk]
I'm sorry this is inaccurate on several counts.
- Every prior release from X3 and earlier (as long as I've been at Cakewalk) always had a mix of both bug fixes AND incremental features. Only the first point release typically addressed emergency fixes.
We're at a danger of quibbling over what a 'release' and a 'feature' is here, but take a look at these patch notes:
http://www.cakewalk.com/Support/Knowledge-Base/20071226/SONAR-7-0-2-Update Sure, the things at the top of that list called "new features" are certainly features from a software development point of view; they add new functionality. But they're not new Features with a capital F. You wouldn't put those up on the packaging or on the What's New page. Most of them are small tweaks that are similar to bug fixes in that they take some suboptimal behaviour and optimise it. And below them, there is a much longer list of bug fixes. With the kind of fixes in a release like that, there is a very low chance of regressions occurring.
With the new system, you obviously still want to fix bugs so that existing members will be happy and renew their membership, but you also have one eye on new customers, every month. New customers want new Features (capital F) and content, otherwise they would have joined already, right? That diverts some attention away from fixes and towards features because you need to deliver the latter every milestone.
Adding new features doesn't necessarily impact other features or create bugs in other features. Its pretty rare when that happens.
Obviously I can't judge how things get broken, but it's clear that they do, and given that all software companies have limited programming and testing resources, it stands to reason that some of the time spent on the drum replacer could have been spent on quality assurance. (I'm not saying that is what you should have done, but we both know there is a resources trade-off.)
As for rarity... these breakages might be rare in the "numerically small" sense, but not in the "what proportion of the releases break something significant" sense.
We have been actively working on improving drum maps, fixing several very longstanding issues that existed in X3 and earlier. You apparently haven't noticed any of those fixes but many others have.
Drum maps worked perfectly for me with no visible bugs from about Sonar 5 onwards. Then they broke in 2 ways in the last 3 months. :) The first way had no workaround, the second thankfully does.
I fail to see the reason for all the negativity and speculation in this thread based on an issue in *one* sub feature.
So, if you break just one sub-feature every couple of months, that's ok? Are drum map users second-class citizens? The reason why you add extra features is because to some people, that 1 new feature, whatever it is, is going to be something they come to rely upon.
Even ignoring that implication, it's not just one feature. There have been a few other areas that were really annoying, such as the Piano Roll view continually changing size in Alston, or the customisable Control Module not remembering edits in Cambridge. These were bugs found by the community within hours of release and which affected a lot of people, so it's hard to see why they made it out of the door.
Here's a concrete suggestion for you: if you're finding it hard to catch bugs like this with the development and QA resources available to you, don't ship a new version at the weekend! Ship it on a Monday morning, so if there's a glaring bug that slipped through, you're already at work and can work on a hotfix. An arguably even better approach would be to do a soft launch where a small subset of users get a day or two to hammer on it before you announce the release.
Here's another one: If it's the case that no part of your testing process involves anybody opening up a project with a drum map in it and playing it back, you might want to add that in. :)