Should m-p packages re-target to in-support TFMs?

[ViktorHofer]

When libraries were brought over to this repository TFMs were updated to the minimum in-support versions of runtimes, at that time: net6.0 and net462. Libraries in this repo that target net6.0 are:

• System.Json
• System.Runtime.CompilerServices.Unsafe
• Microsoft.Bcl.Hashcode
• System.Data.SqlClient
• System.Net.WebSockets.WebSocketProtocol
• System.Xml.XPath.XmlDocument

.NET 6 went out-of-support on November 12, 2024 and I wonder if packages in this repository should re-target to the new minimum in-support version: .NET 8. For customers, this would mean that consuming a new version of these packages would raise a warning on out-of-support runtimes.

If doing so, the package's major or minor version should be bumped to communicate the breaking change in respect to semantic versioning.

[ericstj]

I'm not sure we'd normally make such a change for components in servicing unless there was a something driving it -- such as a compliance requirement, or strong customer impact statement. Do you think you could try to justify this against the servicing bar?

[ViktorHofer]

We updated to in-support runtime versions when we brought libraries code over, not too long ago. I want us to at least establish principles when to update TFMs and the mechanics of it (think about semver). Updating some of these packages is considered highly impactful so we should definitely think about risk here, i.e. inside msbuild: https://github.com/dotnet/msbuild/blob/e73ffcba1fa42ca60551be5dadbcf05c9ad9d914/eng/Versions.props#L29-L33