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

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

Open
ViktorHofer opened this issue Nov 25, 2024 · 2 comments
Open

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

ViktorHofer opened this issue Nov 25, 2024 · 2 comments

Comments

@ViktorHofer
Copy link
Member

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
Copy link
Member

ericstj commented Nov 25, 2024

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
Copy link
Member Author

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

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