Open WhitWaldo opened 8 months ago
@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.
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.
@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.
Just referencing #1219 so it's not forgotten - can switch to using the [Experimental]
attribute following the move to C# 12 (.NET 8)!
Just found #1046 which essentially concludes the same thing we've covered. At some point, docs should be added that reflect this.
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.
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.