lfm
Maybe an intermediate fix even between regular periods - showing extra concern about the matter.

There were a couple of those early on, so it's possible. But as you allude to based on your professional experience, there are always tradeoffs. In this case, people who want instant bug fixes are at odds with those who want more time spent on testing.
 
 

John
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. 

 
Or why not just google it if you don't know.
http://en.wikipedia.org/wiki/Regression_testing
 
This is central to the issue. Why should I stop talking about it just because you don't know about it? Look it up or start another thread.

Doktor Avalanche

John
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. 

 
Or why not just google it if you don't know.
http://en.wikipedia.org/wiki/Regression_testing
 
This is central to the issue. Why should I stop talking about it just because you don't know about it? Look it up or start another thread.

Because I don't think you know what it is in the sense of how CW does it. Of course you will say you do. 

Anderton
There were a couple of those early on, so it's possible. But as you allude to based on your professional experience, there are always tradeoffs. In this case, people who want instant bug fixes are at odds with those who want more time spent on testing.

That's mischaracterising the problem. Sometimes software gets released in a slightly broken form, and bug fixes take time. But they should not be breaking new things when those fixes are released. (That's the 'regression' people are talking about.) We will never get 'instant' bug fixes - in fact, there are several bugs I've reported over the years that just don't seem to get fixed at all. Others have taken months. It's not ideal, but it's ok. What's not ok is every release to look like "20 bug fixes! (5 of which were fixes for things we broke last time. Plus, here are 5 new bugs.)" It wouldn't have been acceptable in the days of paying just once, because Sonar would have got a reputation for leaving their software in an unreliable state. But now that we have the membership, people are being more lenient because they assume it'll just get fixed later. And that is not a positive step.

Doktor Avalanche
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.

 
The bottom line isn't about a specific bug. There were regression bugs in the yearly model, there are regression bugs in the monthly model, there will be regression bugs no matter what model is adopted because humans are involved.
 
The bottom line is about whether on balance the new model is better than the old one. Per your point, of course there could be several ways to tweak the model, like your suggestion of having one release be "fix all drum map issues." But the irony is some drum map issues weren't fixed under the yearly model. Now they're being addressed, and I suspect that has a lot to do with the adoption of the monthly model. (And as pointed out, it seems there's a workaround for the current problem while we wait for a more elegant solution.)
 
 
 
 

.
 

As a bystander I must admit that to me it seems 30-50% of SONAR forum posts have recently been related to
problems with these additions mentioned. One day, a few weeks ago, I just noticed I have no clue of what people are writing about. Only a few threads here and there were something I could perhaps participate.
That sure doesn't make it tempting to move from good old, safe 8.5. ( Ok, maybe I'm just bitter for not having the
means to upgrade my gear :o/ )

Kalle I suppose then I shouldn't break the news to you about the hundreds of bugs 8.5 has, that were fixed in subsequent releases :) Our bug database doesn't lie.

Anderton: Stating that the initial release of X3 was also premature without doing enough testing is not really the best excuse for doing not enough testing now. And it misses the point that monthly releases inherently don't allow in depth testing of the full system for time reasons.

For X3, all future bug fixes were included in the initial price, for the membership model only bug fixes for a limited time are included. As pointed out before by others, a bug introduced in the last month I payed for, may not be fixed without paying again, even if it is a show stopper. But sure, once I paid for a software, I'm at the grace of the developpers if they fix something or not, no matter what release model is used.

The very problem of the new model is that there is no drive for a final stable version. Obviously, because there is no such thing like a final version.

lfm: Would be nice to have a confirmation for my problem. Seems no-one else reported it, but hardly anyone looked at that thread anyway.

In total, the question is always how much effort is put into doing new features - which is important to get new customers - and how much into doing bug fixes (be it for stability or usability) to keep existing customers. Unfortunately, market mechanisms favour the first over the second, because existing customers often stick to their initial decision for various reasons like not wanting to pay for or learning another software.

I hope Cakewalk will find a way to do their membership model in a way that favours stability and usability over new features. As a customer, I don't want to install updates each month just to test if it works better for me than the last release or not.

John
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. 

 

Doktor Avalanche
Or why not just google it if you don't know.
http://en.wikipedia.org/wiki/Regression_testing
 
This is central to the issue. Why should I stop talking about it just because you don't know about it? Look it up or start another thread.

 

John
Because I don't think you know what it is in the sense of how CW does it. Of course you will say you do. 

??? You want to turn this into how to do regression tests topic?
The only thing I (and everybody else should) care about is Cakewalk doing effective regression testing. What you are writing is a total distraction to what I was actually talking about... You've found a buzzword and now decided to concentrate on that.

Kylotan
It wouldn't have been acceptable in the days of paying just once, because Sonar would have got a reputation for leaving their software in an unreliable state.

You're forgetting that when doing the yearly releases, SONAR did have a reputation for being unreliable. Have you already forgotten about the shape X1 and X2 were in immediately upon their release? Or Alex's dozens of bug threads dominating the front page when X3 was released (which were one of the main reasons those bugs got fixed)?
 
That reputation finally started turning around after five months of X3 updates, and the progress made during those five months was one of the reasons for looking into a model that would allow bug fixing to continue every month. Furthermore, there have been tons of posts from people who find Platinum much more stable than even X3. I am one of those. I work with SONAR virtually every day, and have a basis of comparison that stretches back to the original SONAR in 2000. There is no doubt that based on the work I do, Platinum is by far the most stable version of SONAR yet.
 
Also I question your estimate of 25% of fixes in a release being devoted to fixing bugs caused by previous releases. I haven't seen that percentage is any of the bug release lists so far.