In a comment on my last post someone asked me why in-place upgrades are better than side by side upgrades. I thought it worth a post, but it’s an opinion piece more than a technical piece.
Honestly, if I was on the committee that said “side by side or in-place?” I don’t know what I would have voted. This is a really hard problem and they didn’t invite me to the meeting. But I will summarize where I think we stand nearly two years later. If you want review, this Scott Hanselman post and the linked Rick Strahl post cover it.
Before I tell you why in-place upgrades are better, let me tell how they are worse. They are scary. Really, really scary. An in-place update means you can get a midnight phone call that your application in production is broken. You can get this because a third party tool throws an error it didn’t use to throw, and only throws that error in an obscure data scenario. And the only thing standing between you and this disaster – is Microsoft’s competence. Yeah, I think that’s very scary.
Scary enough that I spent weeks researching the known breaking changes and summarizing their impact in what I think is a much-watch 45 minutes in my What’s New in .NET 4.5 Pluralsight video. The languages teams are the best at considering, avoiding and communicating about known breaking changes. CLR/Framework ranks a ways down and some ancillary teams like Workflow suck at it.
So why should Microsoft ask you to take such an astounding risk? Why ask you to stake the future of your company on their (Microsoft’s) competence?
Because the world is moving at an astounding pace. The notion of “cadence” (I so hate this use of that word) is that releases will be frequent and small. Not because some big mucky muck at Microsoft declared releases will be frequent and small – but because that is the world that our industry has created. It’s there in Open Source, it’s there with your phone’s OS upgrade, it’s there with response to new security threats, and it’s there because of a world clamoring for new features.
Let’s say Microsoft updates .NET twice a year. In three years, side by side updates would mean there were six copies of .NET on the user’s machines. It would mean third party tools would have to test against six scenarios (or themselves force an update which would be really bad). You’re application libraries would have to be coordinated across six versions – probably meaning that many devices had multiple copies of libraries used by different versions of your different apps. It would mean your libraries had to load side by side too.
And it might not be a cheap little desktop with all the memory and all the hard disk space and inexpensive power you could ever want. It might be a phone, a tablet, or a cloud system you’re paying to access.
And with rapid updates the line quickly blurs between what’s a real release (4.5 or 4.5.1) and a stability release (like the important Jan 2013 release). You have to keep up with all the change to know when to move forward from a technical perspective.
And if all that wasn’t enough, the concept of the .NET framework has fundamentally shifted. Behind the scenes it’s tied up into many, many little satchels. It’s not a small set of three or six frameworks. The ability of Microsoft to test all combination of the presence of different parts of the framework to work across a large number of in the wild releases would be impossible. In-place releases mean things are updated as needed into a finite case of tested scenarios.
And finally, there’s the security implications of needing to keep not just one or two versions tidied up with security releases, but a very large number of branched framework versions.
In the end there must have been a weighing of options. The demand that we trust Microsoft competence to avoid changes that break your app lined up against a nightmare web of multiple side-by-side framework versions. And there was a third choice – not to move so fast. And there are people reading this that think it’s blatantly clear that each of these three options was the only logical one.
Not going to the fast cadence would have doomed .NET to a historical footnote as opposed to the best bet for the next decade of development. Side-by-side releases has no option but chaos – on our hard drives, in our test strategies and in Microsoft’s security and testing scenarios. The path they chose is the one that can have a good outcome. If they prove competent – and the languages and framework teams get passing marks so far – we all get to live in a sane world.
The backward compatibility commitments Microsoft made regarding the in-place upgrades are the most important commitments Microsoft has ever made. We have to hold their feet to the fire and remind them of that every day, every year for the next decade. We best remind them by testing our apps with CTPs and release candidates on test machines.