Why isn't Microsoft branching C#, .NET, CLR for major changes (horizontal versioning)?

This isn't like new versions where newer versions will still have backwards compatibility.

What I mean is something like, when the designers of C#, .NET, CLR realize that they made a mistake or they overlooked something that could be hugely beneficial but now they couldn't pursue it because of backwards compatibility, they could branch the appropriate product say like by designating it in a different manner (horizontal versioning).

Wouldn't this be more future-proof?

You can say this would be a nightmare, but there would be restrictions like you can't mix and match different branches unlike t开发者_如何学运维he different languages that are compatible with each other, etc (in the same branch).

This way you would say use C# 4.0, then there is something very beneficial that you could use from C# 4.0 B1 (branch 1) and just use that, even though it might require some porting effort.

Is this not a healthy development strategy, where new projects could always start using the latest and the greatest, meaning the latest version and the latest branch of a particular language (C# 6.0 B4 for example)?

I don't see any extra hassle in keeping track of things for newer languages where you already have to know things for each version anyways. So this just adds another dimension (horizontal versions) to vertical versioning.

What would be the potential pros/cons for this development strategy?

There is a huge benefit to having a large set of libraries available for a platform. Currently, if I write a .NET 4.0 application I can reference libraries which were created way back on .NET 1.1. This means that there's a lot of existing code that I can take advantage of, and this is one of the major selling points of .NET.

If I understand your proposal correctly, then if library A is written against C# 4.0B1 and library B is written against C# 4.0B2, then there is no way that my application can be written to reference both library A and library B. This would fragment the platform and make it a much harder to justify the investment in writing C# applications or libraries.

Of course, there are also costs associated with backwards compatibility (look no further than Java's implementation of generics...), but in my opinion the benefits clearly outweigh them. Having a vibrant community using a language or platform makes it easier to hire developers, to find libraries with useful functionality, to get training and support, etc. These network effects are all put at risk by creating incompatible islands within the platform.

Actually, this is a bit like the way Open Source detractors used to argue Open Source projects would end up going. After all, you, I or anyone else could take any Open Source project and fork it into a different branch tomorrow.

Thankfully, the only case where this would gain any traction in the community though, is where we either took it into a specialist rôle (so that it didn't really compete with the original project, just builds on a common ancestor), or where there was massive dissatisfaction with the way the original project was run (where it's sort of a nuclear strike option in Open Source politics).

The reason it was used as a bogeyman argument against Open Source is that it would just be impossible to keep track of which version of which version of which version of which version of a given library, framework, language, component, etc. could work with which version of which version of which version of which version of another.

Luckily, whether open or closed, such branches would die a natural death in the face of the "market" (whether that market was economic or otherwise).

Many (larger) shops have enough trouble keeping up with the major revisions of .Net that are already coming out. This strategy might work for a platform that is not the predominant development platform worldwide, but for Microsoft (and many developers) it would be hell.

Backward compatibility is taken very seriously at Microsoft, especially where developers (the lifeblood of the company since Windows took off in the mid-90s) are concerned. Breaking changes have unknowable impact due to the scale of Windows, and latterly .Net, adoption. Would you want to be the guy who had to explain to Steve Ballmer why your cool fix in the new minor version of .Net broke the apps on which GE (say) run their business? There is immense effort put into making sure that legacy apps and devices will continue to run. Increasing the matrix of versions to be tested would inevitably lead to corners being cut, and we all know what happens next, right?

You can counterargue that nobody has to adopt the latest. But who here does not install Windows SPs as soon as they come out, to avoid the drip-drip of hotfixes for security issues? There is a natural inclination to want the latest, though that has to be balanced vs stability concerns.

.Net has gone a good way to removing DLL hell from the Windows developer lexicon, and to some degree decoupled developer platform progression from OS releases. I don't think the majority of Windows developers are in a hurry to see that change. Love them or hate them, Microsoft have gotten very good at managing large, infrequent releases of what is still the world's de facto desktop standard. It will be interesting to see how Google manage the same problem, as Android takes that spot in the mobile market over the next year or two.