search

Lanayx / Oxpecker

ASP.NET Core based F# framework
https://lanayx.github.io/Oxpecker/
MIT License
283 stars 11 forks source link

Augment target audience: support net7.0 #8

Closed knocte closed 9 months ago

knocte commented 9 months ago

Quoting your Medium article:

I don’t believe that people will switch the framework in their existing projects anyway, and for the new projects newer .NET is an obvious choice.

Obvious choice? Well, is newer always better? In general, yes, but this is not a black&white scenario. Newer is good, especially if you are starting from scratch, but how new? bleeding-edge new? pre-release new? nightly new? There's many shades of grey here.

And that's why we have qualifiers for releases: for example, Ubuntu 23.04 might be newer than Ubuntu 22.04, however the latter is an "LTS" release and that's why many business stick to it and only upgrade to the next LTS release: so that they upgrade to a more battle-tested platform and avoid all the bugs (that other early adopters can catch on behalf of them).

And this is why changing the target framework here from net8.0 to net7.0 might increase your target audience: there may be sysadmins out there that are hesitant, or simply cannot, upgrade to .net8.0 yet. An example is that if you install Ubuntu22.04.3 (LTS) today and try to install the package dotnet8 (with apt), it doesn't exist. However, dotnet7 does exist.

So why limit Oxpecker to only early adopters that can consume net8.0 today instead of increasing the target audience to potential adopters by supporting net7.0? Especially given that Oxpecker isn't really making use of any feature of .net8.0 so it is essentially not a requirement. Let the consumers of your library update their .net runtimes at their own pace.

Lanayx commented 9 months ago

@knocte Thank you for the suggestion! Have you checked this link https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu#install-net, it describes how to install dotnet on Ubuntu 22.04, which is LTS. Moreover, the .NET 8.0 is also LTS, thus is why I chose it as target and not .NET 7.0. Adding support of the new framework is easy, however dropping support is not, so I don't want to have this problem in future. I also don't have a goal of having as many early adopters as possible, simplicity of maintenance has a higher priority for me.

knocte commented 9 months ago

Have you checked this link https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu#install-net,

My friend, I know that .NETCore is compatible with Linux from day one, but I'm talking about Ubuntu-native packages here, which means that they truly come from the opensource codebase (vetted by Canonical), so that you don't need to install external software sources manually, increasing your potential risks.

dropping support is not

I disagree. The day you start depending on some new .net8.0 feature, for example, you simply increase a major version (e.g. from 1.x to 2.x) and call it a day. SemVer conventions allow you to add breaking changes.

I also don't have a goal of having as many early adopters as possible

How about contributors? If I cannot consume Oxpecker libs myself from our companies' servers, I doubt I will continue contributing.

Lanayx commented 9 months ago

I'm talking about Ubuntu-native packages here, which means that they truly come from the opensource codebase (vetted by Canonical), so that you don't need to install external software sources manually, increasing your potential risks.

I understand that, but specifically for Microsoft and .NET 8 it's not a security question, but rather political (knowing that 23.10 already has support of .NET 8). With .NET6 packages in LTS became available in August, I expect it to happen much earlier with .NET 8. And if you don't trust microsoft servers with packages, you shouldn't trust Nuget (microsoft server) and me (3d party publisher) as well.

The day you start depending on some new .net8.0 feature, for example, you simply increase a major version (e.g. from 1.x to 2.x) and call it a day.

It will still disappoint people that for some reason got stuck on .net7.0 and used the project (I've had such experience already). So from my experience it's better not to step into that at all. Moreover, I don't believe that you can build Oxpecker sources with .net7.0 sdk today, since it's already using some newest F# 8 features.

If I cannot consume Oxpecker libs myself from our companies' servers, I doubt I will continue contributing.

I understand and I'm very sorry for that, but having less maintenance is a top priority for me and will allow me to maintain project and contribute for a long time. As a workaround you could just maintain your own fork with .NET 7 support for a few months, till Canonical starts supporting .NET 8 on LTS, publish it to Nuget or private feed and then just easily switch to Oxpecker nuget once the support is there.

knocte commented 9 months ago

and me (3d party publisher) as well.

Funny you say that because I was planning my next contribution to be CI steps to upload the nuget package automagically.

I don't believe that you can build Oxpecker sources with .net7.0 sdk today, since it's already using some newest F# 8 features.

Oh which ones? Anyway, this PR is not changing how the proj is built, but how it can be consumed.

It will still disappoint people that for some reason got stuck on .net7.0

So the logic goes like this? "As I may break up with you in the future and I don't want to make you suffer, then let's rather not start dating at all" lol!

Lanayx commented 9 months ago

I was planning my next contribution to be CI steps to upload the nuget package automagically.

I'll appreciate that, if you make your own fork, it will work for you as well, just the name of the package will be different.

Oh which ones?

For example this line, haven't searched further.

Anyway, this PR is not changing how the proj is built, but how it can be consumed.

Yes, I understand, but building with one OS and consuming with another can be an issue for your CI anyway

So the logic goes like this? "As I may break up with you in the future and I don't want to make you suffer, then let's rather not start dating at all" lol!

Unfortunately, we all have to deal with the trade-offs, in my case this is the tradeoff I decided to make. I understand if you decide to not contribute anymore, life is life.

Lanayx commented 9 months ago

Closing as not planned (.NET 7 end of life is May 14, 2024)