Skip to content
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

Improve target frameworks and their package references: #514

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

SymbioticKilla
Copy link

Hi @adamrodger,

sorry for PR before creating an issue to discuss.
I think it is easier to discuss it within PR, if you are interested in this change.

1.) Add net8.0 as a target framework to support latest LTS version and to use latest compile improvements with less package references
2.) Add conditions for package references => net8.0 doesn't need them
3.) Remove net462 => netstandard2.0 is already a compatibility mode framework to support all .NET versions. There is no need to specify old .NET frameworks.
4.) All projects except nuget projects can reference only net8.0. There is no need for multiple target frameworks

1.) Add net8.0 as a target framework to support latest LTS version and to use latest compile improvements with less package references
2.) Add conditions for package references => net8.0 doesn't need them
3.) Remove net462 => netstandard2.0 is already a compatibility mode framework to support all .NET versions
4.) All projects except nuget projects can reference only net8.0. There is no need for multiple target frameworks
@adamrodger
Copy link
Contributor

Hi - I'm not currently looking to drop explicit .Net Framework or older .Net versions, which is why the project deliberately targets .Net Standard.

If we explicitly support a .Net version then there are two major disadvantages:

  1. Every time a version of .Net goes out of support then PactNet will need to make an explicit breaking change to update the supported frameworks, even though the code itself doesn't require that

  2. Anyone still using an older version can't upgrade, which potentially leaves them open to serious bugs or security vulnerabilities.

Whilst one might say that people shouldn't be on older unsupported versions, the realities of life are that lots of people are. I don't think it's the decision of PactNet to refuse those people the chance to upgrade when there's a very simple solution - target .Net Standard and remain agnostic of the version of the runtime in use.

I think I'd need to see very compelling advantages to outweigh those large negatives, and I'd request that in future an issue is raised as per the defined contribution guide to discuss this beforehand. This is especially important in the case of breaking changes.

@SymbioticKilla
Copy link
Author

SymbioticKilla commented Aug 16, 2024

Hey,
thanks for replying! 🙂
I think there is some misunderstanding.
There are two target frameworks in my PR: netstandard2.0 and net8.0:

  • netstandard2.0 supports all versions. There are any breaking changes for users in the term of .net version support.
  • net8.0 as latest LTS uses less references and use latest compile improvements. It brings benefits for users that stay up-to-date.

My PR just make some improvements in target frameworks organization without any breaking change.

YOU54F and others added 8 commits October 24, 2024 21:21
The DiUS pact-net workshop is out of date.

We have created a new repo under the pact-foundation org 

https://github.com/pact-foundation/pact-workshop-dotnet

which is a hard fork but applies updates to Pact-Net 4.5.x / .NET 6

It at least puts it under our control for maintenance so we can update in a timely fashion and apply contributions from the community
This involves a breaking change in the FFI packaging for MacOS which was
introduced in version 0.4.21:

https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.4.21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants