Skip to content

Conversation

@thompson-tomo
Copy link

Adds in Net 6 so that STJ can be provided by the framework

Closes #141

@airbreather
Copy link
Member

📄 Maybe, but this one isn't as much of a no-brainer as adding a netstandard2.1 target to avoid a System.Memory reference in NetTopologySuite proper.

Pros:

  • In probably every situation where this is possible to do, the System.Text.Json package doesn't need to be downloaded to your package cache.

Cons:

  • Because System.Text.Json is updated with practically every .NET release, the instant that we need something higher than what's in net6.0 (e.g., if something like c2df4bb comes up again), then it is required to adjust how this dependency is handled in net6.0 (probably by removing the special net6.0 target) and then also ideally add another higher TFM to preserve the same "no need for the extra package in your cache if you're keeping up with upgrades" behavior. This is error-prone.
  • As ever, switching from single-targeting to multi-targeting adds another dimension of complexity, and especially with a gulf as wide as netstandard2.0-vs.-net6.0, there is serious temptation to use it with conditional compilation, which is a GREAT feature in general but can come with hidden costs that I don't think are often fully understood.

On balance, I am slightly opposed to this, but that second "con" hides a bit of a "pro" within it that makes me not want to try to shut this down entirely. That "pro": if we can get through the initial inertia of setting up appropriate automated testing that will cover all the conditional-compilation branches that we choose to add, then we can write code that will work better on newer platforms without completely leaving .NET Framework in the dust.

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

Successfully merging this pull request may close these issues.

Add additional TFM to eliminate explicit dependency

2 participants