-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
13.8 is a breaking change from 13.5.2 (SemVer should have bumped this to 14.0) #1044
Comments
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. |
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. |
@colinangusmackay you know what work needs to happen to get it back to standard? |
@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. |
Too outdated! @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.
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: