Atm Serilog 3.X targets net462;net471;netstandard2.1;netstandard2.0;net5.0;net6.0;net7.0 and will continue to do so.

This was arrived at organically. Going forward, the TL;DR of the policy of what to target is:

• we support net462, net471 and netstandard2.0 where possible.
• Where there are compelling features that dictate targeting newer TFMs, we favor the lowest even numbered TFM >= net6.0.
• Odd-numbered target frameworks get trimmed on major version releases (netstandard2.1 and net5.0 included).

This implies that Serilog 4.X will likely target the following TFMs: net462;net471;netstandard2.0;net6.0.

Reasoning

This issue replaces #1966 and comment threads such as serilog/serilog-sinks-console#145 (comment).

There's been requests to support net8.0 etc, inferring based on the above broad range. If we have a clear strategy in the core package and repo, the other sinks can follow. [Longer version]

Production assemblies

For production assemblies, the following rules apply for picking TFMs, the following rules should apply:

• In general, if netstandard2.0 is insufficient, we target the lowest even numbered netX.0 TFM that will work. i.e. a light sink would target net6.0 (as opposed to targeting net12.0 just because it's there)
• non-LTS TFMs should not be targeted unless there's a reason:
  • e.g. if .NET 9.0 adds a new API that lets us do something significantly faster etc
• on a major version bump, we trim outdated non-LTS targets (e.g. if net10.0 is out, we remove net7.0 and/or net9.0 targeting
• net462, net471 and netstandard <= 2.0 won't be aggressively trimmed
• netstandard2.1 and net5.0 will be considered as non-LTS (so will be replaced with net6.0 on next major)

For this repo, that means V4 should:

• remove netstandard2.1, net5.0 (ideally they would have been removed in V3 but the ship has sailed)
• if V 3.10 had added a net9.0 target (because it needed a new API that was not in net8.0), V4 would remove that and replace it with net10.0

For the Console sink, the above rules would imply:

• it should target netstandard2.0.
• it should not target netstandard2.1, netcoreapp3.1, net5.0
• it may target net6.0 if and only if there is something that can not be achieved via netstandard2.0.
• bu, targeting net6.0 does not imply supporting net7.0 or net8.0 or any other later one.
• if net9.0 added API that's the only way to deliver a compelling new feature and/or significant perf increase, it could be added as part of the feature PR for that

Test assemblies

• out of support frameworks do not need to be tested and can be trimmed any time (i.e. can trim net5.0 any time)
• At least one in date version should be in the targets at all times
• non-LTS coverage is optional (i.e. when net9.0 is available, we can add it to the list, but there is no SLA demanding it)