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

#141 Add net 6 to enable removal of STJ #142

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

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