-
-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Target frameworks: why so many? #159
Comments
This is just a legacy thing from before I was owner. I think the original idea was to copy Newtonsoft.Json as this package follows that to some extent |
@matt-lethargic I don't know if having different reverse-compatible target frameworks actually makes a difference for end users, so I'd need some time to research that. So far my assumption was that frameworks after EOL (so far this would be all .NET Framework 3.5/4.0/4.5) should be deprecated in favor of .NET Standard or .NET 2n+1 (major LTS). This way we don't try catering to a minor percentage of users still using deprecated frameworks, but still have ways to introduce new QoL features in new releases without much trouble. Also, expected to see a |
We have done some consolidation and updating of the target frameworks in #180, so I guess we can close this issue. |
Is there a specific need to have so many target frameworks?
I was under the impression that it's easier to target the lowest possible version, which is compatible with any newer version by design.
So this way we would have
net35
instead ofnet35;net40;net45;
andnetstandard1.0
instead ofnetstandard1.0;netstandard1.1;netstandard2.0;netstandard2.1;
.I may be missing something here, so please feel free to point out the reasons for this set of target frameworks.
The text was updated successfully, but these errors were encountered: