I think the concern about new versions is overblown. Sure, there are going to be some bugs, but there were bugs before installing a new version. If a couple people say they're having problems with an update, the forum gets paranoid...I say just download a new version and try it. Rollback has always worked for me, but I've not needed to do it except to compare changes to previous versions when writing the eZine.
 
I don't care if there's a bug in a new feature, because I didn't have the feature before so I can obviously live without it. If there's a regression bug, it matters only if it's in a function I use. Worst case is I rollback until the bug is fixed in the next update but I haven't had the need to do that yet. For example, I didn't care when the Custom buttons on the Control Bar were stuck on the right side of the Control Bar for a month. If I had really considered that a death blow to my ability to make music, I would have rolled back.
 
 

Anderton
I think the concern about new versions is overblown. Sure, there are going to be some bugs, but there were bugs before installing a new version. If a couple people say they're having problems with an update, the forum gets paranoid...I say just download a new version and try it. Rollback has always worked for me, but I've not needed to do it except to compare changes to previous versions when writing the eZine.

I agree about rollback, but the issues for me and others are very real and should not get glossed over and trivialised . We should all accept there will always be issues with new software, but that does not make it a trivial problem.

What most expect on the monthly release is the same consistent quality, and that just can never happen. On the other hand if you alternate between new feature releases and pure bug fix releases, on a predetermined cycle (whatever period of time is chosen between the two),that the customer is made aware of, the customer will know when and what to expect, and will have some sort of guidance on what sort of update schedule would be most suitable for them. Their expectations can be better managed.

i.e. New features all the time with more risk on a monthly cycle, or slow but steady when updating on quarterly (assuming bumper bug fixes happen on a quarterly basis).

The new monthly updates have been working well for me. Most months I wait at least a few days to gauge the response here on the forum(there are always plenty of early adapters). In all these updates I have yet to roll back. Sonar just works well for me. I'm not a power user in the same way others are, so many of the reported bugs don't seem to affect my workflow. Of course there is always room for improvement, but Sonar has been very stable and productive for me. Actually, all the way back to Sonar 2.

joel77
The new monthly updates have been working well for me. Most months I wait at least a few days to gauge the response here on the forum(there are always plenty of early adapters). In all these updates I have yet to roll back. Sonar just works well for me. I'm not a power user in the same way others are, so many of the reported bugs don't seem to affect my workflow. Of course there is always room for improvement, but Sonar has been very stable and productive for me. Actually, all the way back to Sonar 2.

That just proves different customers want, use and perceive things different ways.

If you don't use all of Sonars features you are likely to find a simpler workflow that just works for you. Statistically you are less likely to have problems because you just use less. Of course the day something happens to your workflow then you get worried, so you roll back and everything is fine again.

If you are a 'power user' you are likely to get into it's more complex areas, and end up using more of the functionality on offer, I think you are more likely to come across problems, it's just stats. If you roll back you may end up out of the frying pan into the fire because again you are still simply using more of it.

Noel Borthwick [Cakewalk]
The flaw in your reasoning is that you assume that bug fixes cannot cause other problems and that only new features cause bugs :)
In fact most of the time new features are less likely to cause regressions in other features since they are built on top of existing functionality. The exception of course is when a new feature touches a bunch of other stuff.
 
That said we may consider offering a model in the future where we do not offer new features at all but just bug fixes. Its actually a great deal more work for us to maintain but it seems that enough people still prefer the older software model.

Maybe you wouldn't have to make entirely separate models of that:  Cakewalk Commander is already giving us options of what we want to install or update.
 
If you just treat all bug fixes as separate items we can choose to upgrade or roll back, someone who's in the middle of a lot of work and can't afford any hick-ups could choose to apply just fixes for issues he's actually experiencing and if the fix causes some unfortunate problem, he can roll it back.
 
 
I realize its more work one way or the other, since you have to determine when to make the rollback unavailable or force inclusion of certain updates, once other updates depend on that code.
 
It seems better for users, as they wouldn't have to make a blanket decision to join one or the other model. Everybody would still be in the same program - the granularity you are already offering, on what to update would just get finer... 
 
This maybe less disruptive to your existing work flow?  IDK, maybe its even more work for you this way, but if you could get an effective system going for this, it should make people pretty happy - one could hope  ;-)

n13L5
If you just treat all bug fixes as separate items we can choose to upgrade or roll back, someone who's in the middle of a lot of work and can't afford any hick-ups could choose to apply just fixes for issues he's actually experiencing and if the fix causes some unfortunate problem, he can roll it back.

It all sounds so easy, yep it makes sense if it could actually be done, but sadly rolling out targeted bug fixes would make everything WAY too complex to debug as that would mean hundreds of different built combinations of Sonar out in the field.

MS used to do it this way but with Windows 10 that roll out model has changed (more like Cakewalks) as it took a heck of a lot of development and support resources. MS realised like Cakewalk they simply could react quicker with rolling updates.

BobF
One of the advantages the old model had was the ability to install versions side x side.  Rather than bugfix only updates alternating with feature updates (or a variation), *I* think having the ability to install the new along side the previous would be better.
 
This way my beloved Hopkinton version could remain unchanged when I install Ipswitch.  I can kick the tires on Ipswitch while having Hopkinton still available-without rollback/forward and such.  I could continue working my in-progress projects with Hopkinton while trying out Ipswitch with project copies.
 
If there is something about Ipswitch I can't live with, I can continue to use Hopkinton until an update gets Ipswitch settled out.  Or maybe I leave the Ipswitch side until Jovial is released.  I update Ipswitch to Jovial while continuing to rely on Hopkinton for bread/butter.  Once I have confidence in Jovial, I can start using it.  The next update goes to the Hopkinton "side".
 
IMO the rollback process is very slick, but in practice updating with rollback as a fallback still "feels" like I'm messing with my production environment more than I would prefer.
 
Adding "side x side" version capability to the current model would be the best of both worlds IMO.

 BobF, what do you mean by "in practice updating with rollback as a fallback still "feels" like I'm messing with my production environment"?
 
I guess I don't understand rollback as well as I should. I thought that rollback meant that the latest version gets uninstalled and the version to which you are rolling back gets reinstalled, so you are going back exactly to the prior version. Am I missing something? 

No you aren't ! :)
The ultra cautious like me do a backup before upgrading as well.

Uhm, please elaborate ... what are you backing up? As in, an Acronis disk image type backup? What are the steps you take? I'm also ultra-cautious. Absolute scaredy-cat in fact.
 

Acronis trueimage backup.
The backup is probably only useful if the rollback goes wrong (which is never so far).