Akka.net: Target .NET Standard 2.0 and newer only

[Aaronontheweb]

Version: 1.4.0 beta and beyond

As part of the v1.4.0 release we are now targeting .NET Standard 2.0, instead of .NET Standard 1.6, and long-term we plan to stick with .NET Standard as the "guts" of Akka.NET.

However, we are also still dual-targeting .NET 4.5.2 - a version of .NET that is getting quite old and is missing some features (i.e. some of the TaskCompletionSource flags) that we currently have to hack around.

Going forward, I would like to propose the following roadmap for how we manage the versions of the .NET runtimes that Akka.NET targets:

• v1.4.0 - .NET Standard 2.0 only
• v1.4.* - .NET Standard 2.0 & .NET Core 3.0 - this would be done as a part of "spanifying" parts of the Akka.IO, Akka.Persistence, Akka Serialization, and Akka.Remote systems in order to improve performance. .NET Core 3.0 would enter into the picture as a means of gradually moving our "spanification" efforts down into the serialization and I/O layers, which require access to APIs that are not available in .NET Standard at the moment.
• v1.5.0 and beyond - .NET 5.0? Who knows.

Here's the strategic question we have to wrangle as maintainers: how do we balance getting the best possible experience for Akka.NET users with supporting our enterprise users, many of whom are stuck with .NET Framework for the time being?

Technical purity is usually the losing argument here - Akka.NET needs to create as wide of a tent as possible, but supporting .NET Framework 4.5 in perpetuity isn't sustainable long-term either. I might answer this question by polling the Petabridge mailing list, but I wanted to invite some open discussion on Github first.

[poke]

I don't use Akka but I think your roadmap looks good. However, whenever targeting .NET Standard 2.0, I would also suggest to keep dual targeting the .NET Framework since that makes the consumption from the framework easier. You can push the version up to 4.7.2 or even 4.8 though.

From a business perspective, supporting one of the latest versions of the .NET Framework will also allow customers that still have to rely on the framework to plan a long term migration strategy without locking them out immediately.

[netclectic]

I would have though there's no point explicitly supporting anything from 4.7.2 and above, as they are fully .net standard 2 compliant.

So, the question has to be how many existing Akka.Net users are there out there stuck somewhere between .NET 4.5.2 and .NET 4.7.2? Find out the actual extent of the problem before coming to any conclusions.

[Aaronontheweb]

So, the question has to be how many existing Akka.Net users are there out there stuck somewhere between .NET 4.5.2 and .NET 4.7.2? Find out the actual extent of the problem before coming to any conclusions.

That's my biggest worry - we have a lot of users in highly regulated industries (medicine, finance, government, publicly funded research, etc) and while I'm sure the individual developers who work in those organizations would love to move onto .NET Core / newer .NET Framework versions, which runtime they have to support is often not up to them entirely or at all.

We must have a wide tent that includes them.

Petabridge normally does a survey of all of our Akka.NET users on our mailing list every year and historically we've leaned on that data for this type of platform decision. I think we're due for another one of these for 2019 - and I'll drive, specifically, at this question here and share the results after it's been collected.

There's no need for us to make a decision on this overnight - best to get a wide range of input first.

[nagytech]

Out of all the developers who are constrained by legacy systems, it would be interesting to see the distribution of what version of Akka.NET they are all using. And, out of the portion of developers _not_ on the latest version, how comfortable they would be moving to the latest version. When I was working in such environments, bumping a minor version without a significant business case was seen as a large risk. So, if you were to drop support for 4.5.2 in the near future it's safe to say these developers are not affected. Like netclectic said, the survey can help identify the likelihood of this impact.

From my own perspective, I think there's a line we can draw to say "It's reasonable to support [x.x.x] as a minimum .NET version." We can push that line closer to more modern versions by using the .NET Standard and .NET Core compatibility matrix, and supplementing with preprocessors for conditional code. Akka.NET is already taking advantage of this in some places, so it's just a matter of finding the balance.

I was a big fan of Play Framework and Lagom Framework when it first started, and it was usually every month or so I was faced with a breaking change. But, I think both of those frameworks would be drastically different today if they didn't embrace change. Although I don't have the same level of following with my .NET port of Lagom framework, I try to maintain an opinionated approach to changing for the better.

Overall, I think it's reasonable to draw the line somewhere but still provide or encourage community level patch level support for those left behind.

[Aaronontheweb]

Survey data from about a year ago - 178 total respondents:

About ~19% of the surveyed users were running on .NET 4.5 or earlier.

I'm going to get a new version of this survey prepared and send it off to our mailing list first thing tomorrow.

[Aaronontheweb]

Forgot that we had asked this question directly on that survey as well

[Aaronontheweb]

Mailing out a new survey about 30-40 minutes ago: https://akkadotnet.typeform.com/to/YwCV7O

Received 50 responses so far.... Going to let this marinate over the weekend before sharing the results.

[Aaronontheweb]

Results are in from the survey, largely the same group of people from 2018 (mostly Petabridge mailing list) https://akkadotnet.typeform.com/report/YwCV7O/S9DIEgI8jHeyTjF8

200 replies roughly. You can see the numbers here. I don't know how representative they are of the wider ecosystem, but it's the best data we have. Shows that it's safe to go forward with this change.

[Aaronontheweb]

Need to implement https://github.com/akkadotnet/HOCON/issues/151 as part of this.