[BUG] 6.0.1 requires dotnetsdk 8 but doesn't say that

Describe the bug
Had a build tied to 6.* for a version using sdk 6 and it failed with

Data collector 'XPlat code coverage' message: [coverlet]System.TypeLoadException: Could not load type 'Microsoft.Extensions.DependencyInjection.ServiceCollection' from assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
   at Coverlet.Collector.DataCollection.CoverletCoverageCollector.GetDefaultServiceCollection(TestPlatformEqtTrace eqtTrace, TestPlatformLogger logger, String testModule)
   at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionStart(Object sender, SessionStartEventArgs sessionStartEventArgs) in /_/src/coverlet.collector/DataCollection/CoverletCoverageCollector.cs:line 135.

To Reproduce
build with dotnet6

Expected behavior
Expect coverlet to run and report successfully

Actual behavior
fails to generate report

Configuration (please complete the following information):
Please provide more information on your .NET configuration:
* Which coverlet package and version was used?
* reproduceable with 6.0.1
* Which version of .NET is the code running on?
* 6.0.x (tried a few versions...all reproduced)
* What OS and version, and what distro if applicable?
* window 10 and linux ubuntu (whatever azdo is using now a days)
* What is the architecture (x64, x86, ARM, ARM64)?
* x64
* Do you know whether it is specific to that configuration?
* seems not to be

Additional context
the changes in this PR #1601 seems to force having dotnet 8 installed so that thinks like System.Text.Json will load the 8.0 version from the shared framework.

❗ Please also read Known Issues

doesn't appear to be any

overall, seems like mistake to break backwards compatability between 6.0.0 and 6.0.1 like this...doesn't seem to match semver...but maybe that was your intent? understand 6 is EOL at end of year so we should be moving to 8 sdk soon...

Thank you for reporting.

I used the coverlet HelloWord example and the test was executed successfully.

The .NET SDK 8.0 was installed.

@Bertk

Same problem here.. All our CI pipelines are failing because we are adding coverlet.collector dynamically to our test solutions via dotnet add package.

@Bertk the hello world example still uses PackageReference Include="coverlet.collector" Version="6.0.0" > => Version 6.0.0

dotnet add package will install version 6.0.1 (a patch update that must not contain breaking changes according to SemVer) and this package does not include any dependency to system.text.json at all.

Have same issue. We're using .NET 6 SDK and have coverlet.collector referenced as 6.0.*. Having such a breaking change in a patch version is quite a surprise. Changes described in #1626 require at least new minor version.

@MarcoRossignoli

Sorry, I missed the to update the version.

@MarcoRossignoli @daveMueller We should update the version to 6.1.0.

Another idea: "SuppressDependenciesWhenPacking" is set on the collector - effectively hiding all dependencies. Would it be possible to pack these two required package references as dependencies instead or something similar?
The breaking behaviour could thus probably be reverted for .NET < 8

@Bertk

@Bertk would it be also possible to release 6.0.2 with reverted changes?

@SeWieland

@SeWieland Thank you for the hint but coverlet.collector package has no dependencies. The dilemma is the support for framework net6.0, net7.0 and net8.0 and this works with the latest packages for

    <PackageReference Include="System.Reflection.Metadata" VersionOverride="8.0.0" />
    <PackageReference Include="System.Collections.Immutable" VersionOverride="8.0.0" />

@MarcoRossignoli

@MarcoRossignoli @daveMueller We should update the version to 6.1.0.

Why? we bump the patch we will bump the minor if we ship a new feature and a major if we do breaking change.

@MarcoRossignoli

@MarcoRossignoli coverlet 6.0.1 is a bugfix version but requires a .NET 8.0 SDK.

semver 2.0 has this paragraph

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

but requires a .NET 8.0 SDK.

Why? we ship for

so we're good for .NET Framework and every project with tfm >= 6.0

@SeWieland

@SeWieland Thank you for the hint but coverlet.collector package has no dependencies. The dilemma is the support for framework net6.0, net7.0 and net8.0 and this works with the latest packages for
    <PackageReference Include="System.Reflection.Metadata" VersionOverride="8.0.0" />
    <PackageReference Include="System.Collections.Immutable" VersionOverride="8.0.0" />

IMHO if there is support for .NET 6.0 it now has dependencies. If I have to pin other packages to a specific version for coverlet to be compatible, that package is a depdendency... Therefore, right now my workaround is to pin coverlet to v6.0.0 in all .NET 6 projects.