Note that .NET Core is, more or less by necessity, much smaller than the full .NET framework. The latter isn't going anywhere or being deprecated. Think of Core

Note that .NET Core is, more or less by necessity, much smaller than the full .NET framework. The latter isn't going anywhere or being deprecated. Think of Core as just another subset of APIs that happen to also work really well on other platforms. We had that already with Silverlight, Client Profile, and other things. Since .NET 4 introduced a new runtime (just as .NET 2 did; due to that I'd also say that 4 was not just a minor upgrade) all subsequent versions so far run on the same runtime and just change the libraries. MS got a bit of complaints for a confusing versioning scheme: .NET 2, 3, 3.5 that all used the same .NET 2 runtime, but had different library capabilities. It seems to me that they are doing this better with .NET 4: Every 4.x version runs on the .NET 4 runtime. .NET 5 will likely do the same again, once it is released. They also changed another part: All .NET 4.x versions are drop-in replacements for .NET 4.0. That's why, when you look in the C:\Windows\Microsoft.NET\Framework directory, you see v1.0, v1.1, v2.0, v3.0, v3.5, but only a single v4.0, which on my machine is actually 4.6.(probably 1). All this doesn't mean they cannot iterate on the runtime itself, though. Recently we got a new JIT for example, and I think the GC also got some upgrades. And keep in mind, this is the release announcement for .NET 4.6.2 – a minor upgrade over 4.6.1. Naturally you won't see major new features added. ____________________________ > Plus several APIs turned out to vanish pretty quickly and are dragged along as legacy like WinForms, Silverlight, WPF, Managed C++, ManagedDirectX and its next incompatible iteration, SharePoint APIs, WinFS, etc. Plus the incompatible different API WinRT aka WinRunTime aka UniversalRuntime with various incompatibilities in WinPhone8, Win8 & 10. Most of those are completely separate products and are not part of the .NET Framework. You can argue that Microsoft is happy to create new APIs and let them die, but the vast majority of those are not in the actual framework. ____________________________ > In comparison Java is source compatible to at least v1.4,but in reality often back to Java 1.1 or 1.2. Uhm, that very much depends on the features you use. Sure, if you eschew generics, auto-boxing, annotations, enums, foreach loops, and a lot of other language features. Especially 1.5 brought a lot of things that permeate many Java codebases. In 1.1 you'd have to live without collections, XML, regex, and a few other things. I don't doubt Java codebases exist that could meaningfully go back to that compatibility, but I'm not convinced they're that prevalent. (I know, especially in Enterprise, Java version uptake is slow. In my observation this currently amounts to Java 6 being the version usually used. Back when 6 was current, it was usually 1.4 and earlier.)