Runtime: Adopt semantic versioning to manage interdependency within core .NET ecosystem

[gulshan]

Current .NET ecosystem has some major components-

• CoreCLR
• Roslyn
• CoreFX
• netStandard
• SDK
• ASP.NET
• VIsual Studio
• CoreRT
  etc

The current practice has been- lumping all of these components together in a major .NET release. But as the whole .NET ecosystem getting more open and larger, this way of interdepencey is getting more complex to manage. I think it is true both inside core .NET dev teams and other developers using these components. Netstandard promised to fix backward compatible library development. But still there are lots of issues.

So how about adopting semantic versioning in the core .NET componets, to manage dependencies? Each component will have its own development and release plan. And everyone will develop on a solid release version of component they are depending on. Earlier version still gets feasible new features. When Roslyn dependes a new feature in CoreCLR, that dependency should be stated in versions, not in ad-hoc basis. And the new Roslyn features not requiring CLR changes can be shipped to multiple versions.

This movement will not be simple or easy. But can this be worthy of discussion?

[svick]

The current practice has been- lumping all of these components together in a major .NET release.

Not really. VS 2019 has already been released, but C# 8.0 and .Net Core 3.0 are planned to be released later.

Each component will have its own development and release plan.

I think that's more about the marketing and project management aspect of versioning, not about the technical side. And I think we as a community don't have much influence on that.

And everyone will develop on a solid release version of component they are depending on.

I don't think that would work. At least C# features are often developed in concert with corefx and that includes seeing how pre-release versions of both components work together and improving the feature based on that, often including breaking changes in corefx. If Roslyn had to wait for a fully released version of corefx, it would mean that:

1. Development of the feature would be unnecessarily slowed down, since the two teams couldn't work in parallel.
2. The feature would likely end up being worse, because it couldn't be tested in the environment in which it's meant to be used.

Earlier version still gets feasible new features.

If you're talking about backporting, then that is possible and does happen sometimes. But it's also a lot of work, that would have to be justified. And then there's also the Long Term Support version, which is specifically intended for people who value stability over new features. How would your plan affect that?

When Roslyn depends a new feature in CoreCLR, that dependency should be stated in versions, not in ad-hoc basis.

How is that better? With the current approach, if I need to stay on an older version of .Net, I can sometimes still use a new language feature by using a polyfill library and your proposal would prevent that.

Also, what about other flavors of .Net? If I want to write ".Net Ore" (special version of .Net for mining machines), that supports some of the features of .Net Core 3.0, but not all, I can easily use the existing C# compiler. With your proposal, I guess I would have to somehow teach Roslyn about .Net Ore and that doesn't seem desirable to me.

---

To sum up: I think this approach has lots of drawbacks, but I don't see the compelling benefits that would be required to offset those.

[Nirmal4G]

@svick @gulshan They are using versioning but not all of them follow SemVer. Also all the problems, you have described, exists in the .NET Core ecosystem today!

I know how important backwards compat is but they are taking it too much far. I mean, if you're not going to make runtime changes at least for every major version, then what the point???

I followed many great features that were dropped because of them requiring runtime changes. E.g.: nullable ref types, unified async await, extended enums (like in swift), better generic structs, extended linq, extensions everywhere, better native interop, to name a few!!!

[Happypig375]

@Nirmal4G The features you mentioned are not only runtime changes, but ecosystem changes too. You have to think about libraries and applications that target older platforms which will not benefit from these changes. This is why .NET 5 is so important - it is one unified platform that runs everywhere so updates are centralised.

[Nirmal4G]

@Happypig375 Not what I was talking about but True. Also .NET 6 will be the final form, not 5. 5 is more like an RC to me.

Also every runtime change is also an ecosystem change, so it is implied. 🙃

[terrajobst]

We have stopped with the idea that we can ship the .NET platform as a loose set of components, e.g. on NuGet. We have unified vision for the product itself (which, for example, is reflected by the new framework names for .NET 5 and we have the plan to make certain parts of the .NET platform optional components.