search

benruehl / adonis-ui

Lightweight UI toolkit for WPF applications offering classic but enhanced windows visuals
https://benruehl.github.io/adonis-ui/
MIT License
1.7k stars 143 forks source link

⬆ Update to .NET Core 3.1 #115

Closed database64128 closed 3 years ago

database64128 commented 3 years ago
benruehl commented 3 years ago

Thanks for the contribution. However, I am not sure if increasing the framework version should be done. Doesn't this drop support for .NET Core 3.0 Apps? My understanding was that the lowest supported version should be targeted. If a dependent project targets .NET Core 3.1 it can use the library already.

database64128 commented 3 years ago

Most projects already did the update. I think it's safe to go.

https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit/blob/86ce490efa87fb8b7071ccaf7173f64668bea2fe/MaterialDesignThemes.Wpf/MaterialDesignThemes.Wpf.csproj#L4

https://github.com/reactiveui/ReactiveUI/blob/6acfcb3ea20c63d1f6c02a3d7db242df478b18c5/src/ReactiveUI.Wpf/ReactiveUI.Wpf.csproj#L3

benruehl commented 3 years ago

What exactly is the advantage of increasing the version? Loosing support for .NET Core 3.0 would be a disadvantage so there should be an equally large or larger advantage to compensate the loss.

I'm sorry if this sounds ungrateful in any way. That is not intended. I see that some projects changed the version while others included both versions. I just want to understand what implications this brings and why.

database64128 commented 3 years ago

.NET Core 3.0 has already reached EOL 5 months ago. .NET Core 3.1 is a LTS release and will be supported by Microsoft for 3 years. I see no point of continuing the support for an EOL version.

benruehl commented 3 years ago

Even though it might have reached EOL there might be users who build on Core 3.0. It should not be the responsibility of this library to make those users upgrade. .NET 4.5 has reached EOL as well and still MaterialDesignInXamlToolkit (which you linked) supports it. That's because it is the lowest version the library can support. If users want to go with an EOL version they need to live with the implications. But it is not on me to take away their tools.

That changes of course when there is a need or an advantage to drop support for Core 3.0. But currently I don't see any because you can use the library with Core 3.0 and Core 3.1 just fine.

It would make sense to include netcoreapp3.1 as well if this makes any difference for a depedent project which targets .NET Core 3.1. Up until now, I couldn't find any proof that this is really the case though. But I'm okay with including it anyway. Mostly because most other libraries do so as well, so maybe there is a reason I just missed.