Shane Krueger

Option 5 most definitely has the least impact on the GraphQL specification. This is likely a good indicator that it presents the least changes existing codebases.

> I agree with the need for this; it would make changing a field from a non-list type to a list type a non-breaking change. Currently it's only non-breaking when...

Summary from November 2023 WG: Two viewpoints: - @leebyron Currently once variable coercion is complete, the remaining codebase can use variable values directly, without further coercion rules. With this change,...

Version 1.x will retain compatibility with: - .NET Framework 3.5 - .NET Framework 4.0 and newer - .NET Standard 1.3 and newer The above implicitly include all .NET Core versions....

I don’t think the conventions project was ever made to be compatible with GraphQL.NET’s attributes for its type-first definitions. You might check that you’re referencing GraphQL.Comventions.NameAttribute and not GraphQL.NameAttribute.

There's been hardly any changes since v4; just a couple bug fixes. I've tried to assist making the minimal changes to keep the repository to compile with the latest versions....

Certainly. I wrote this more of a discussion/preview/review of a potential approach.

System.Drawing.Primitives doesn't include System.Drawing.Color, so it does not seem to have any benefit. Base64QRCode requires `Color` to use for .NET Standard 1.3 without changes to the API, and so this...

> By adding a reference to System.Memory package this change could also be done for .NET Desktop. I wouldn't. There has been so many performance enhancements in .NET Core since...

The reduction in allocations is very impressive!