Versioning WPF
Versioning is a fascinating topic to me because it's such a hard problem. The goal is to ensure a high level of compatibility without sacrificing the ability to innovate. There's two major strategies -- "roll forward", where old programs always use the latest version of WPF, and "side-by-side", where multiple versions of WPF can coexist on the same computer and old programs use the version of WPF they were designed for. Both can work, Microsoft has used both at times, but they come with some hard trade-offs.
The problem with roll forward is that any change is potentially an incompatible change. Before I came to Microsoft, I thought compatibility was easy -- don't change any API signatures, and you're compatible, right? If only it were so. Applications have been broken by fixing a memory leak (they used data after they freed it). By fixes to buffer overflows (they passed in too small a buffer and didn't care about the memory that got clobbered). By the order in which virtual methods get called. By recompiling a function with a different compiler (some applications copy system functions and patch them). By changing parameters to an internal function. By returning screen coordinates that weren't possible on previous versions of Windows. Etc.
So the reality is, with a roll forward strategy, there's no such thing as perfect compatibility. And for a really widely used program like Windows, the only way to achieve a Windows level of compatibility is with lots and lots of testing, together with a lot of shimming. Shimming is where Windows patches an application so it can run successfully -- it's expensive to test the applications, it's expensive to write shims, and you never get every last application -- but it's better than not being compatible.
Side-by-side says that nothing is as compatible as the platform you developed against, and that no amount of features or perf work in the newer version is going to outweigh compatibility. But side-by-side has its own problems, namely that you're dealing with an explosion of versions. Ten versions later, does every computer need ten versions of WPF? Having 10 copies taking up disk space and memory is an obvious problem, but that's not even the biggest problem. How do you test it all? Because now, you need to make sure WPF versions 1-10 all work with the rest of Windows 2016. Remember, there's always some component that can't be side-by-side (having side-by-side desktop window managers would be pretty weird), so you need to retest everything with each version of Windows.
It gets worse. If you have to test it, you also potentially need to change it (Windows doesn't shim Windows!). Plus, a released version actually changes over time -- think of security patches and service packs. And there's even issues about which compilers you use -- every version of Windows uses a different version of the Visual C++ compiler. So if you have N versions of Windows, you're looking at N * (N+1) / 2 different WPF binaries to test -- and you need to test all of them if you come out with a security patch that affects all N versions. And we haven't even begun to talk about mixing and matching different versions of different DLL's!
So a realistic side-by-side plan has to constrain this somehow. One proposal I've heard (and as far as I know it's just a proposal) says that you cap the number of supported versions in accordance with Microsoft's support lifecycle. And you version of all the side-by-side DLLs together -- no mix and match. And WPF 2006 on Windows 2009 will be the exact same binary as WPF 2006 on Windows 2006. Which limits the number of binaries and puts a cap on N, although it's still an N * (N+1) / 2 test matrix since you need to test them on all the different versions of Windows.
So where does WPF stand in all this? Right now, we're doing the only sensible thing -- we're keeping our options open. We're trying hard to be extremely compatible in case we do roll forward. But we're also making sure we support side-by-side. Because right now, we just don't have the data we need to make an informed decision -- how many applications are going to be using WPF 1.0, and what kind of compatibility problems will they have with WPF 2.0? Pretty hard to say when you haven't even finished beta two. <g>
