Download bugfixes only ?

Hello fellow Sonarians,
I'm quite new to the Forum. Hope I haven't overseen any similar questions already answered/discussed.
 
In the new rolling-updates model, is it possible to download bugfixes only?!
 
To illustrate what I mean:
Previously I would have bought Sonar X3 as is with all the included content and features. Then as bugs would become apparent "updates" were released.
For example.
- Sonar X3 was released end of September
- X3b update beginning Oct. 2013
- X1e update mid March 2014
During these six months all of the updates have been bug-fixes or product enhancements (keybindings / workflow) and not new product-features (eg. Vocalsync/Drum-replacer) or additional content (eg. expansion packs/ FX chains).
So in the end I am left with a product as is (content & featurewise)and with most bugs fixed. The product is sort of "finished"
 
Now in the current rolling-update model whatever my last update is, it not only  included bug-fixes to the previous version(s) (which we obviously need, and I feel are entitled to)  but also included new product-features and thus most certainly new bugs to those features..... I.e. I will always be "stuck" with a version that is "unfinished" and with unfixed bugs.
Now I know that a product might never be 100% bugfree, and that bugfixes to a certain feature might not be fixed by the next update-release (it might take 4 or 5 releases) but I would like to see a possibility to reject new product-features, and choose to install bugfixes only....
 
What do you guys think about this?
Maybe someone from Cakewalk could give us their opinion on this.
 
Cheers, Mat

M@
Hello fellow Sonarians,
I'm quite new to the Forum. Hope I haven't overseen any similar questions already answered/discussed.
 
In the new rolling-updates model, is it possible to download bugfixes only?!
 
To illustrate what I mean:
Previously I would have bought Sonar X3 as is with all the included content and features. Then as bugs would become apparent "updates" were released.
For example.
- Sonar X3 was released end of September
- X3b update beginning Oct. 2013
- X1e update mid March 2014
During these six months all of the updates have been bug-fixes or product enhancements (keybindings / workflow) and not new product-features (eg. Vocalsync/Drum-replacer) or additional content (eg. expansion packs/ FX chains).
So in the end I am left with a product as is (content & featurewise)and with most bugs fixed. The product is sort of "finished"
 
Now in the current rolling-update model whatever my last update is, it not only  included bug-fixes to the previous version(s) (which we obviously need, and I feel are entitled to)  but also included new product-features and thus most certainly new bugs to those features..... I.e. I will always be "stuck" with a version that is "unfinished" and with unfixed bugs.
Now I know that a product might never be 100% bugfree, and that bugfixes to a certain feature might not be fixed by the next update-release (it might take 4 or 5 releases) but I would like to see a possibility to reject new product-features, and choose to install bugfixes only....
 
What do you guys think about this?
Maybe someone from Cakewalk could give us their opinion on this.
 
Cheers, Mat

Welcome to the forum. I think you need to try the new model and see for yourself if an update adds new bugs or not.
 
I have been around a very long time and have updated Sonar starting with the very first one Sonar XL. Clearly in all those updates there have been bugs. The interesting thing about that is most of them didn't impact me in any way. A very few seem to impact me alone. While others were major for others and not much of an issue for me. 
 
You need to rethink how you are approaching this and see what works for you not what may be reported by others.  

Noel Borthwick [Cakewalk]
 
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.

 
IMHO the world does not need 2 Sonar Platinum versions (w/ and w/out new features); it would be a waste of resources and only adds confusion.

Although I was skeptical about the new way of doing updates first (who wasn't???) I'm very convinced now. In fact it's really simple:
 
If you like your current version and don't have any showstoppers, stick with it and just read the eZines to learn about the new stuff. Keep your version until there is something in the updates for you that will improve your workflow. Updates are cumulative, you don't lose anything if you skip a few (I just went from Foxboro to Ipswich because in between versions did not contain any fixes/improvements that were critical to me).
 
If you are upgrading blindly on the first day of every release, you may risk getting into some trouble occasionally (like with any kind of blind updating these days) ... however, it's easy to rollback to the version before so no real risk there ...
 
 
 

Noel Borthwick [Cakewalk]
So we thought as well, but the concept of constantly evolving software is still alien to some users and they refuse to accept otherwise. As you state, we have explained in all the FAQ's about the flexibility to update at any point but sometimes people don't like making choices :) Perhaps those of you who get it can try and convince others about the value!

I'm still on Gloucester. I don't mind being on Gloucester for the moment either, and I totally agree with you. I don't see any value in having a separate bug fixes path (i.e. different code base), that would be a waste of time. I'm also all for the monthly release cycle (although I wonder if things would have been better if it was every 2 months, but whatever).
 
I also don't mind waiting for regression fixes either. The main issue seems to be when regression issues get fixed, along comes a new release to break something else. Life would be so much better if there were regular dedicated regression fix releases happening (which also fixes legacy issues as well), so we knew when to expect them. I again stress NOT on a separate codebase but part of the standard release cycle. Then we would have some real choice.

Cheers..

We discussed that ad-nauseum last year. Side by side installation actually creates a can of worms with anything that is shared and would also be very confusing for less savvy users. Tech support would also be a nightmare.

I couldn't begin to imagine the kind of uproar that kind of release pattern would cause on the forum. Theres enough problems now with panic about the new method that people don't like let alone complicate the whole thing by running two releases of the same version as you suggest.

If you're on a release that you find stable, in this case H and you upgrade to I and don't like it you can roll back to H and pick it up again when J comes out. The last released version will always have all the updates and fixes accumulated along the way.

I'm more prone to try and sell it to the forum in general how Noël suggests.

FreeFlyBertl

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.
 

Side by side versions never were really separate version - just think about all the "Shared *" folders that e.g. installing X3 changed but were originally from "X2" ... so only the latest version was a true tested release version, all other (older) versions turned into some sort of hybrids (not even considering 3rd party software that changed over the years) ...
 
If you want true separate versions, you need two PCs ... use one main PC where you keep the productive Platinum version, use the other PC (any PC will do) to check out new versions ...

The old way was whole lot closer to sxs than the current system.  In practice it worked exactly the way I described.

Noel Borthwick [Cakewalk]
We discussed that ad-nauseum last year. Side by side installation actually creates a can of worms with anything that is shared and would also be very confusing for less savvy users. Tech support would also be a nightmare.

The fact that a discussion was continued ad-nauseum doesn't guarantee the correct conclusions were drawn from it
 
No doubt this would need careful design.  Could even be optional such that only those with the greatest concern would want to adopt the approach.
 
Of course the easiest approach for both sides of this is to wait out each release, allowing early adopters to screen.  Then update when the dust settles.  Anderton has been rightfully promoting this idea of a self-regulated update intervals. 
 

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.
 
 

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  ;-)

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? 

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.