Jason Zander replied to that email I sent him on Friday. I'm glad he responded, but to be honest, he's being way too evasive. Here's what he wrote:
Hello Rei – Thank you for your mail. I appreciate your feedback and passion on this subject. The .NET Framework has always provided rich feature support in several areas such as engine and base class libraries, web, presentation, data, xml, and networking (including web services). In each new release we strive to add additional support to match new standards and incorporate features our developers request to make their jobs easier. The main “pillars” in what we referred to as ‘WinFX’ historically represent advancements in several of these feature areas. For example, Windows Presentation Foundation provides a new presentation technology and Windows Communication Foundation provides advanced web services support. Windows Workflow and CardSpace add business process workflow and a new security identity system to the Framework. As such, we’ve always thought of these technologies as advances to the core .NET Framework and not simply an adjacent technology. Having two names for the technology has proven to be very confusing and hence we have always been on a path to figure out one name to advance. In the end we decided to continue the .NET brand, in which we have made a significant investment in since its release in 2001.
Given this as context, I do not think having both a .NET Framework and WinFX as separate entities will be clear since each new version of the framework support is advancing key feature areas. For example, as the industry advances the WS* protocols, what software would I install to get that support? Is it only in WinFX? Only in .NET Framework? Both? With our naming clarified, the answer will always be a latest version of the .NET Framework.
In reading through your feedback, I see a few specific concerns that center around the use of the major version number as an indicator for the CLR version. Using 2.1 or 2.5 would clearly indicate that both are based upon CLR 2.0. But let’s look at a couple of the related concerns you brought up:
• Why not create a brand new version and call it 2.1? The CLR binding mechanism treats major.minor as distinct values for version binding. That means if we created a 2.x release with one installer, it would have to be installed side by side with 2.0 to work. This solution creates a new set of work for everyone: new tools to target both 2.0 and 2.x, another full framework to deploy to end users and in the enterprise, etc. Our goal with using the base 2.0 engine is to not restart that clock and introduce a new version to have to target. Using 2.5 (your second option) is really the same as this one, but giving an allowance to a bigger version gap to help indicate the scope of the features added.
• Which version of C# do I use? We implemented side by side technology to help with versioning and application compatibility. Because of this, even if we were to name the version of the .NET FX with LINQ support 2.7, there would still be a new C# compiler with this build. You will have the same set of installer issues and multi-targeting of compilers.
• The use of V3 instead of V2 seems to indicate V2 is already obsolete. I understand your concern on this one and the type of confusion it could cause. I do worry about the counter issue: if major versions of the software come out now and in the future but we only change the minor version number, it belies the major investment and advancements we have made in the system and could lead those not as familiar with .NET as yourself to underestimate our commitment to the platform.
I’m sure you have already seen it, but I recorded a Channel 9 video in July to cover a lot of these topics which may be useful for review:
Thanks again for your feedback and passion on this topic, and for using .NET! I hope I have been able to clarify some of our decision making process and rationale for the plan we are executing on.
Last Visit: 31-Dec-99 19:00 Last Update: 10-Feb-16 15:36