Skip to content
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

Consider dropping some legacy framworks #128

Open
SimonCropp opened this issue Jul 7, 2024 · 5 comments
Open

Consider dropping some legacy framworks #128

SimonCropp opened this issue Jul 7, 2024 · 5 comments

Comments

@SimonCropp
Copy link
Contributor

so we can leverage newer .net features

  • span
  • ireadonlylist
  • ireadonlyspan
@SimonCropp
Copy link
Contributor Author

IMO net6, netstandard2, net472

@mmanela
Copy link
Owner

mmanela commented Jul 8, 2024

@SimonCropp Thanks for filing this. I am not against dropping older support if we have a compelling change to make (like adopting span to improve perf). However, one of the goals I have for this project is being maximally compatible so that any improvement can help the greatest number of projects even if they are stuck on very old framework versions. So, I want to weigh improvements against that view and make sure the improvement is worth the loss of compatibility.

Thoughts?

@SimonCropp
Copy link
Contributor Author

my reasoning

  • net472 was released in 2018-04. and it should be trivial for people to move to that from net47 which was released in 2017-04
  • net6 was released in 2021-11, it is the current LTS version, supported till 2024-11. net5 went out of support in 2022-5. net3.1 went out of support in 2022-12
  • netstandard2 is a catch all for some extension based frameworks that require libs to target netstandard2. eg roslyn analysers, c# source generators. there is a negative side effect that netstandard2 implies support in earlier frameworks (eg 4.6.1 and netcore 2.0) but in my projects i handle that with documentation

Up for debate is if u still want to support 4.6.2. released in 2016-8 and supported till 2027-1. u can see the APIs added in net47 https://github.com/microsoft/dotnet/blob/main/releases/net47/dotnet47-api-changes.md
i think the only problematic thing in tuple support. there is a polyfill package System.ValueTuple, but it not seamless. AFAIK it was the first attempt from MS to back port a language feature to an earlier runtime. if u google 4.6.2 tuple u can see some of the problems.

As for api+langfeature compat, we can use a polyfill lib.

Refs:

@mmanela
Copy link
Owner

mmanela commented Jul 10, 2024

@SimonCropp Thanks for the detailed response and I am supportive of this. Ideally, we would do this change along with improvements that take advantage of the newer framework versions.

@SimonCropp
Copy link
Contributor Author

@mmanela ok. i will gradually make changes and trim TFM as required. and we can discuss in each PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants