When I complained on Scott Hanselman's blog (on something of a tangent I admit) that the versioning of the .NET Framework was nonsensical, he asked me how I would have done it. I think he was subtly trying to point out to me that its not as easy as it looks. But I already knew that. Obviously trying to come up with a system for describing a platform of technologies and tools in a way that makes sense to techies and non-techies alike is a challenge. But the way it has been done so far doesn't seem to make sense to anyone, not even the people who came up with it.
I think part of the challenge is the way .NET can be versioned side by side. This makes it somewhat unusual in the world of technology platforms. Usually, new versions of software are intended to replace older versions. Upgrading from one version to the next means you no longer have the older version around, but you use the newer version instead. This is even true for the Java runtime. The typical end-user doesn't have mulitple versions of the Java runtime installed at one time; he upgrades from one to the next. .NET is different in that major versions are intended to live side-by-side, so traditional versioning schemes don't necessarily make sense. However, it seem to me that, given the circumstances, the appropriate thing to do is come up with a versioning scheme that does make sense, and apply it uniformly. And for the life of me, I simply cannot come up with a scheme which accounts for what we have seen so far with the .NET Framework. Here are a few examples:
- Relatively minor changes and additions to the .NET Framework 1.0 were called the .NET Framework 1.1. Similarly scoped changes and additions to the .NET Framework 2.0 were called the .NET Framework 2.0 SP1. Seriously folks, what is the point of using decimal version numbers if you are going to attach a separate name like SP1 instead of incrementing the decimal?
- .NET 1.1, a minor version increment, included a new CLR, new libraries with new features, and changes to existing libraries. .NET 3.0, a major version increment, included ONLY a new set of libraries with new features. .NET 3.5, a minor version increment (but a big one), includes a new set of libraries, and changes to existing libraries.
So how should it look? I don't really know, but I have a few ideas:
- Most importantly, the CLR and BCL need to be versioned separately, primarily because of the technical support implications of a new CLR that do not exist with the BCL. Supposedly the advantage to keeping them under the same umbrella is that non-technical decision makers don't have to understand the difference. The problem is, in reality they DO have to understand it. Upgrading from .NET 1.1 to 2.0 required it departments to deal with a whole new set of trust relationships for the new runtime. When I started talking to my employer about using .NET 3.0, I was immediately shutdown because of the perceived effort of doing the same configuration all over again. I was forced to explain to them that whereas 2.0 included a new runtime, 3.0 did not, so it did not require the same effort to "upgrade". The perceived benefit of maintaining a single umbrella was lost.
- I would prefer that orthogonal technology releases like the WinFX set not be released as new versions of the .NET Framework, but instead as "extensions" or "components" which are dependent on the .NET Framework. It would make the versioning story so much simpler. However, since I know that's never going to happen, the WinFX release should have been .NET 2.x. The minor version increment indicates that this is an optional upgrade; if the particular features available in the new version don't apply to your situation, you can stay with what you have. Contrast this with .NET 2.0, where generics enabled scenarios that simply weren't feasible before, and they applied to everyone. My company certainly had no use for any of the technologies in .NET 3.0 at the time it was released, but because it was a major version leap, there was the perception that we were "falling behind" by not upgrading. Sadly that was probably one of the motivations of the MS marketing team that made the decision.
- .NET 3.5 should have been .NET 2.X+1. Again, there simply is nothing here that is applicable on the order of generics that justifies pushing everyone in the world to upgrade. I'm not downing LINQ; I love LINQ. And I find LINQ to SQL to be somewhat useful in certain situations. Expression trees are fun to play with, and have some extraordinary uses in advanced scenarios. Extension methods are like playing with fire, but that can fun too. But in terms of justifying time, expense, and risk of upgrade, there is just not enough to say that it should be applied across the board. (I am quite certain all of the LINQ-ophiles are going to charge me with heresy for this, but I stand by it.)
So that's what I think. Is it better than what we have now? I certainly think so, but I bet not everyone does. What do you think?