13.8 is a breaking change from 13.5.2 (SemVer should have bumped this to 14.0)

[colinangusmackay]

Expected Behavior / New Feature

A minor version bump should contain new features or bug fixes only and not break existing builds. If a breaking change is introduced then perform a major version bump. For clarity and disambiguation my definition is major.minor.patch

If this can retarget to .netstandard 2.0 again then that would likely fix the breaking change. If there is a reason that forces Ocelot to target .NET Core 3.0 specifically then it should have been a major version bump. If only certain optional features must target .NET Core 3.0 then these should be removed/refactored to a separate package so that the main package maintains the highest level of compatibility.

Actual Behavior / Motivation for New Feature

Existing .NET Core 2.2 applications fail to build/restore the Ocelot NuGet pacakge because Ocelot now directly targets .NET Core 3.0 rather than .netstandard 2.0 as it previously did.

error NU1202: Package Ocelot 13.8.0 is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2). Package Ocelot 13.8.0 supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0) 

Steps to Reproduce the Problem

1. Update Ocelot NuGet package on an existing .NET Core 2.2 application from 13.5.2 to 13.8.0

Specifications

• Version: 13.8.0
• Platform: Windows 10
• Subsystem: ???

[TomPallister]

Yeh the contributors didn’t bump the commits as specified by gitversion. This wasn’t identified in code review.

Says you need to do this in the docs!!!!!!

I just came back to the project to do the release last night forgot about this part of the process.

Best case is someone ships a PR with a breaking change semver commit.

[colinangusmackay]

Mainly, I don't get why .NET Core 3.0 was targeted at all. To me it doesn't make sense for a class library. The only projects that I've seen target .NET Core x.x are application entry points and tests (which are arguably a type of application entry point anyway). Class libraries should typically target .netstandard in order to be more flexible.

Looking through the repo it looks like #1025 introduced the direct dependency, in order to fix #1001, but that fix has ended up breaking it for those still pre .NET Core 3.0.

We plan to move to .NET Core 3.0 anyway in the not-to-distant future, so for us it shouldn't be an issue for too long.

[TomPallister]

@colinangusmackay you know what work needs to happen to get it back to standard?

[jmezach]

@colinangusmackay @TomPallister I believe that if you want to reference ASP.NET Core 3.0 parts you can only do that by targeting netcoreapp3.0 as far as I know. See also this section in the migration doc.

We did discuss multitargetting Ocelot to both netstandard2.0 and netcoreapp3.0 in the original PR, but I believe it was decided we could just make a breaking change and keep servicing the older versions from a separate release branch.

[raman-m]

Too outdated!
Microsoft supports only .NET 6, 7 and 8 after .NET 8 release in November 2023.
And we do follow the same strategy: support of .NET6-8

@colinangusmackay
I don't get your concern regarding SemVer version.
The problem is not in version numbers, but it is in breaking changes and not informed community about the problem in Release Notes.