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

[Proposal] Deprecate .NET 6/7 support in favor of .NET 8 in fall release #1261

Open
WhitWaldo opened this issue Apr 3, 2024 · 6 comments
Open

Comments

@WhitWaldo
Copy link
Contributor

This is more a placeholder for a later release after November of this year when .NET 6 and .NET 7 become officially unsupported. Following that date in the subsequent release, I propose that the .NET package for Dapr be updated to target .NET 8 and that the language version be updated to at least C# 12 so maintainers and developers can utilize the latest language functionality when adding new features (as was a minor issue when implementing the cryptography functionality in which a feature was only available in .NET 8 and an inferior approach was taken because of the .NET 6 dependency).

This will require updating not only the SDK itself, but also examples, quickstarts and potentially a quick pass through the documentation.

@WhitWaldo WhitWaldo changed the title [Proposal] Deprecate .NET 6/7 in favor of .NET 8 in fall release [Proposal] Deprecate .NET 6/7 support in favor of .NET 8 in fall release Apr 3, 2024
@philliphoff
Copy link
Collaborator

@WhitWaldo Post-November '24 I think it will be easy to drop .NET 7 (which mostly wasn't directly targeted) and add .NET 9. Dropping .NET 6 at that point might be more difficult. While it will be out of support, yes, given how long it seemed to take for it to be adopted from .NET FW and .NET Core 3.0/3.1, I wonder how quickly we can assume people will move from .NET 6 to .NET 8. (Granted, that jump should be easier than prior jumps.) I might be inclined to wait an extra release cycle before dropping .NET 6.

@WhitWaldo
Copy link
Contributor Author

Has there been any discussion amongst the .NET maintainers about the value of even having explicit support for the non-LTS .NET releases?

I recently contributed to a project that's still maintaining a release for .NET Core 3.0 and I found I didn't even have the build tools installed to compile it locally, which upped the difficulty of providing my contribution. It'd be a real shame to have a similar problem here of would-be contributors wanting to provide support for latest and greatest releases but being blocked merely because they don't have the older SDKs installed.

@philliphoff
Copy link
Collaborator

@WhitWaldo That's a fair concern (especially if we intend to keep support for versions past their LTS dates). One option might be to tweak the projects/targets such that only the current LTS version is targeted when building/testing locally and have the CI pipelines build/test/package the rest of the supported matrix.

@WhitWaldo
Copy link
Contributor Author

Just referencing #1219 so it's not forgotten - can switch to using the [Experimental] attribute following the move to C# 12 (.NET 8)!

@WhitWaldo
Copy link
Contributor Author

Just found #1046 which essentially concludes the same thing we've covered. At some point, docs should be added that reflect this.

@philliphoff
Copy link
Collaborator

I've added some additional notes to the issue and plans for goring forward, and updated the 1.14 RC release notes to directly state the deprecation of .NET 7 targeting.

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

No branches or pull requests

2 participants