Simplify target frameworks

[jairbubbles]

Reduce drastically the number of target frameworks while keeping maximum compatibility.
Having so many target frameworks (18!) affects the developper experience:

• compilation is super slow for such a small library
• refactoring takes ages

It will also reduce the package size!

See #2 (comment) for more details

[kekyo]

Sorry, this is a decision based on my experience, but I would like to take a closer look. I plan to use it on several private projects, so I would like to see how it affects them and accept it if it looks ok.

[alastairlundy]

@kekyo Hi, is there any update on this? I'm not a current user of the library but I might make use of it in the future. I noticed the very long TFM list when browsing it on Nuget.

If you're keen to avoid dropping support whilst reducing TFMs, I have the following ideas as a potential starting point: I would suggest dropping the .NET Core 2.0, 2.1, and 2.2 TFMs as they already covered by .NET Standard 2.0, and .NET Core 3.0 and 3.1 as they are covered by .NET Standard 2.1 .

From there .NET Standard 1.6 may be worth dropping as Microsoft has updated their advice to advise against targeting this TFM going forward.

Thanks.

[kekyo]

@alastairlundy Thank you for your consideration!

At this time, there are no changes planned for this matter. Since this PR proposal was made, I've been refining my reasoning to clarify this position. I'll articulate it here.

There are several reasons, but fundamentally, they align with my policy for library projects:

1. Minimize dependencies on base libraries and keep versions as low as possible.
2. Ensure the final deliverable works with all versions at their highest level.

Point 1 enables broad applicability across projects. This principle stems from my own experience repeatedly struggling with compatibility issues between library versions. The current .NET approach attempts to resolve TFM complexity passively by "DISCARDING" .NET Framework/.NET Core/.NET Standard. However, this is still a work in progress (my prediction is it will be achieved in net14 ;) , and production application development based on these older environments still exists.

It's also important to note that the target TFM for development and the runtime version it runs on may differ. There will also be production environments running .NET Core applications on newer .NET runtimes. In such cases, it must be possible to build with the “old” TFM. The problem is complicated because even if you determine the TFM, it doesn't mean the code that references it or the version of the runtime that executes it is fixed.

And through point 2, applications can resolve the latest vulnerabilities and critical bugs. Simply override them with updated package versions in the application project. This is easy to execute. Furthermore, since many NuGet packages ensure backward compatibility, updates can succeed in building and running (exceptions exist).

This may differ from what is simply called a "best practice" policy, but I am confident this is better for library projects.

Furthermore, even if NuGet library packages grow larger due to multiple TFMs, the assemblies actually used are only a selected set of TFMs within it. Therefore, the increased package size does not become an issue for the application.

So, when might this strategy become problematic?

• Whether library developers can set up the environment to build it
• If the library requires TFM-specific implementations, leading to complexity

Here, how much this library project focuses on being "foundational" becomes crucial. The more likely the library is to be widely used (though this can be hard to predict), the more we see this as a key point for improving compatibility—one worth tackling even if it incurs a cost to address the issue.

Does GitReader fit this description? I believe it's a feature that should be treated as sufficiently fundamental.
We're gradually approaching that point, but once we reach a future where no one cares about older TFM versions anymore, we'll be able to remove this entirely.

Where do your priorities lie? If you're simply using the package, broad TFM support is actually a very good sign of well-designed package architecture. This should be a major motivation to consider using it (not just GitReader).