I get it, I'm as horny as anyone else is for the latest and greatest. I want Cakewalk to deliver on schedule, it's something I can look forward to every month. I know I'll be able to distract myself for a couple hours downloading and checking out the newest patches and features. On the other hand, the pressure to produce on schedule can become a quality issue. This is the classic triad of software development: time, quality, functionality.. pick two.
With the latest release, there appears to be a couple regressions. I'm not going to go into specific details, that's not the point of this post. It's more just general apprehension, audio engine stops, things working a little differently, nothing specific. It just feels pushed a little. Maybe it's just the stuff that needs to get done to fix the other stuff that's important, I don't know.
I guess what I'm trying to say is, it's ok not to make the deadline if it isn't quite ready, if you're a couple days late to make sure everything works, no problem. I'm somewhat concerned with a mature code base that something doesn't get broken by a well intentioned code change. Your velocity is your velocity, it's not something that can be pushed externally.
Best

I guess it's one risk with having continuous maintenance updates running - devs may take guard down a bit test less. Not by intention - more unintentional.
 
Still, there are so much software that is to work together that's in reality it's impossible to cover all options.
Me for one, never considered moving Custom Module in control bar, so never noticed problem in Cambridge. And the list of features are endless, and ways to use every option is almost endless too.
 
To complete a checklist with just about every option still won't find all problems.
 
One place I worked, they tried to introduce a selftesting software, some code put in all classes that were supposed to help in this kind of tests. But in reality it was never used by us in devs team - slowed development too much and overall too cumbersome.
 
In the 90's I tried something from Microsoft - just called Test - same thing. What you accomplish does not justify the amount of work.
 
The beta test program announced the other day is way to go - and only way to go. Very different configurations and many ways of using every feature.
 
Especially since updates are each months, there is no couple of days deadline.

With the Big Yearly Updates, there were many issues (some small, some big) that needed to be sorted out right after each release. X3 went up to X3e and although some features were added, those updates were mostly about big fixes. Although I don't have stats, it "feels" like the amount of issues introduced in each monthly update is less than 1/12th of the issues that were introduced after a big update. So, that leaves more time to fix long-standing issues, and I think the monthly releases have been really good about attacking those. Also, if a bug does happen in a new release, when it's quantified (like the Control Bar issue) the fix happens sooner.
 
In a larger sense, software is kind of like the calculus concept where a ball bounces halfway to a wall with each bounce. When does it reach the wall? Well, theoretically, never. With software development, it seems at some point you have to decide when the ball is close enough to the wall to say that it has reached the wall...even if it hasn't.
 
All software has bugs, so a company's challenge is how to manage bugs. I think the monthly model is better than the yearly one. Some companies do public betas, which can be very effective but are not without problems because they generates a lot of "noise." Think of the zillions of posts about "bugs" that turn out to be pilot error or lack of understanding about the program - those all end up tossed in with the legit bugs in a public beta.
 
lfm knows a lot more about this world than I do, so I see his point that a more rigorous, formal beta program is probably a good way to go.

I must say I was a little shocked that the Control Bar bug was released in Cambridge. My first thought was 'did they test this release at all ?'. I skipped Cambridge completely partly because of this and partly because I did not have the time.
A more robust beta test program with more testers is a must with accelerated releases so it is good Cake wants to expand this.
However, the technical aspects of accelerated releases is a separate issue. Cakewalk could have kept with the old payment model and released X4 'A' to 'L' on a monthly basis without all the hoopla.
The new model is about continuous cash-flow pure and simple and has little to do with bug fixes or anything technical.
So just admit it and move on already. It is OK, we understand.
Who would rather be paid once a year instead of monthly?

Anderton
In a larger sense, software is kind  of like the calculus concept where a ball bounces halfway to a wall with each bounce. When does it reach the wall? Well, theoretically, never. With software development, it seems at some point you have to decide when the ball is close enough to the wall to say that it has reached the wall...even if it hasn't.

IIRC, this is called Zeno's paradox and was a legitimate paradox until it was discovered that an infinite series can have a finite sum.

I think the new model wins on every front... Goodies that seem ready are included in monthly updates. Those that aren't go in a future update when they are

Known or reported bugs are dealt with similarly. New bugs which slip by in new content are surfaced quickly by users exploring these smaller chunks of newness and rectified real time within a month.

I don't think this adds pressure at all... I think it affords the means of being a more cohesive community. I'm livin and loving it.

This does seem to be a potential problem that was, if not created by the distribution model, at least exacerbated. Bugs in released software have always been a problem, and thorough and patient testing has always been the suggested solution. Unfortunately that solution has rarely been employed. In the episodic release model the driving force for getting the buggy software out the door was the perceived competition from vendors of similar software, and the need to generate revenue to keep the shop open at all. Now there is a self-imposed deadline, and the promise that new stuff will arrive on a schedule to justify the next monthly payment. Smoothing the cash flow does not inherently solve the problem.
 
Unfortunately, the obvious solution for Cakewalk would be to release true features of the software (which is hard and needs to be done pretty much in house) at much more infrequent intervals, and fulfill the "promise" by bundling a bunch of things like loops and plugins, that can be purchased cheap if modified (Sonar only) versions can be gotten from third parties tapping into their plugin lite/trial version capability. That too has been tried in the sort-of-annual release model with variable results.

microapp
Cakewalk could have kept with the old payment model and released X4 'A' to 'L' on a monthly basis without all the hoopla.

 
Cakewalk did keep the old payment model. They just added another payment option. I don't see any downside to giving customers more choices.
 

microapp
The new model is about continuous cash-flow pure and simple and has little to do with bug fixes or anything technical.
So just admit it and move on already. It is OK, we understand.

In all the discussions about the Membership Program, cash flow was not brought up except as beneficial potential result of the Membership Program. It was never the primary goal, like it was for Adobe. Think about it for a second - it couldn't  be. Unlike Adobe, Cakewalk still let people pay upfront if they wanted to. If everyone had decided to pay upfront (and there was no way to predict whether they would or not), Cakewalk would STILL have done the monthly releases and there would have been no changes in cash flow. Also remember there had been regular requests in the forum for a monthly payment option.
 
The other big difference is that the Adobe model is meant to guarantee cash flow because if you don't pay, the software dies. So they knew upfront the cash flow would be there. With Cakewalk, you have the option to turn off the cash flow spigot at any time and keep using the software, as well as pay upfront.
 
The next logical question is if cash flow wasn't the priority, what was? The main goals of the Membership Program were to pick up more new users, make existing customers happy because they'd be getting fixes more regularly and new features sooner (how soon people forget - there had been quite a few complaints about bug fixes stopping after a few months because work started on the next big update, which was true), make life easier for the dev team, draw attention to SONAR every month instead of just once a year, and shake up the industry to get some mindshare/notoriety by doing something different from Adobe and other subscription models. All those goals are being met.
 
Cash flow is short-term thinking. The thinking behind the Membership Program is much more strategic and longer-term. I realize you'll likely not believe that for whatever reason, but I was in on the discussions and it's the reality - what I know about Cakewalk's decision-making process was from experiencing it, not speculating about it.
 
Of course from a business standpoint, the object is to create something that will allow the company to grow and gain more market share; the gamble is that SONAR will be more successful long-term because more people will see SONAR as much hipper software created by a more responsive company. That's far more important, and a much higher priority, than immediate cash flow.

slartabartfast
Now there is a self-imposed deadline, and the promise that new stuff will arrive on a schedule to justify the next monthly payment.

 
Most of the people who update pay up front. They don't need justification. The new users have already gotten a complete version of SONAR, so the extra stuff every month for another year is just icing on the cake.
 
As to the "self-imposed deadline," it's much more fluid than you might think. There is always continuous development being done at Cakewalk, and there always has been. It's more like whatever is ready is "harvested" every month. There was a feature pulled for Dorchester a couple days before it was released because there was a bug. OTOH the VocalSync noise filter enhancement had not been planned for release, but several of the beta testers found it so useful (and didn't experience any problems) that they urged Cakewalk to release it now.
 
Even my content contributions are subject to change without notice, either because something went together more smoothly than expected or needed more work I hadn't anticipated, or Cakewalk felt certain content was more appropriate for a particular release.
 
The situation isn't like magazines where you have huge lead times that require co-ordination with print runs and such. It really accommodates the nature of software much better. The only way a monthly "deadline" would be missed is if there was nothing to "harvest," and it's almost impossible to imagine that happening.

Oh, and one more thing...the "harvesting" nature of the updates is one reason why there isn't more "coming next release" info.