Version 4.0 release

[Shane32]

https://github.com/graphql-dotnet/graphql-dotnet/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.0

We plan to release GraphQL.NET v4 / Server v5 on February 1.

Originally posted by @sungam3r in graphql-dotnet/server#352 (comment)

@sungam3r Please keep in mind that if we intend to keep that date, we need to keep moving through changes. We need graphql-dotnet/parser#101 merged so we can make related changes in this repo. (Specifically, I want to review the CoreToVanilla converter, unless you're going to, and review the execution process for "precompilation" #2016 .) I need #2165 reviewed and merged so I can continue with additional changes in a new PR for my input coercion work.

I know we are all pressed for time, but if you can review my PRs as soon as your free time allows, then I can continue working (especially now as I have a lot of free time for the next week or two). I will do the same for your PRs.

Keep in mind that we do not have migration documentation written; just some simple bullet points. Based on the v3 release, I anticipate that @joemcbride does not want us to release a new version without a good migration document. I can do this as soon as we can get through the changes.

Finally, we have been adding to the 4.0 milestone without taking anything off of it. We need to review the milestone goals again.

Don't mistake me - I do think we should release 4.0 "soon", and if we run out of time, let's just set our goals and stop there. We should not have 4.0 perpetually in limbo like 3.0 was.

Let's use this topic to discuss and track the progress for 4.0

Last question: Is there anything else you foresee adding to 3.3.0? I don't know of anything.

[sungam3r]

I will review #2165 tonight. I honestly doubt the need for #2016 but until conflicts are resolved there, I will not look into it.
Regarding graphql-dotnet/parser#101 - I will make a corresponding PR here as soon as I can.

Is there anything else you foresee adding to 3.3.0?

I have no preference. I hope that I will be able to work for #1451 but only for v4 of course.

[Shane32]

Ok. I'll release 3.3.0 then. I doubt very much if we have any further changes. And if so, they can probably go into 3.3.1.

[Shane32]

@sungam3r What do you think our timing is for releasing 4.0? I know we are working on a few tasks right now:

• Add global switches #2224 DONE
• GraphType first schema directives #1451 DONE
• Add MS-specific dependency injection extensions #1571 DONE

Do you still want to work these for 4.0?

• [WIP] Introduce ArgumentBuilder #2191 REJECTED
• Memory allocation optimizations #2166 REJECTED

There are a number of issues in the 4.0 milestone. Is there any of those or anything else you want to work on?

I will be happy to do a proper migration document once we are feature-complete (not just some quick bullet points like we have now). It will take a little time but I think @joemcbride would want it completed before we release 4.0. Of course I will need your help for the stuff that relates to #1451.

[sungam3r]

#1451 is my primary goal. I promise to watch #1571 again before v4 release. #2191 is no longer relevant, because it turned out that there is already a fluent api for setting the arguments, I just forgot about it. I will not close the PR because I wanted to add something, but it can be postponed. I'll look into #2166 one more time before v4 to make sure we used all relevant optimizations from there.

Is there any of those or anything else you want to work on?

#1423 if I have time.

[Shane32]

P.S. I need to work on #1571 and update per your comments. I'll tag you when I'm ready.

[Shane32]

@sungam3r What are our remaining goals?

• Fix issues with repeatable directives(?)
• Add documentation for directives
• Finalize migration notes
• Review and merge Add MS-specific dependency injection extensions #2261 (MS DI extensions)

I believe all those tasks are in your court now. Let me know if there's anything else.

Will you have enough time to finish this weekend? I won't have hardly any more time to spend on v4 release.

[sungam3r]

My weekend ends in 1 hour. I do what I can.

[sungam3r]

I think we will finish and merge #2261 tonight.

[sungam3r]

Remaining:

• Add documentation for directives No Custom Directive Documentation #860
• Finalize migration notes
• Length directive and variables visitors Length directive #2276
• Remove unused scalars from SDL Remove unused scalars from SDL #1423
• GraphTypeTypeRegistry rework GraphTypeTypeRegistry rework #2283
• IsValidLiteralValue fix and ValueConverter-related optimizations Add ScalarGraphType.CanParseXXX methods #2293
• Fix issues with repeatable directives Fix UniqueDirectivesPerLocation validation rule and Directives class to support repeatable directives #2260 [MAIN BLOCKER FOR V4]

[sungam3r]

@Shane32 I'm going to fix #2260 this weekend. All the remaining PRs are waiting for the review. I'm not going to do anything else before the v4 release. We are almost close to the release.

[sungam3r]

@Shane32 I almost fixed #2260. Within the next 6 hours I will send a PR.

[sungam3r]

Fix for #2260 is ready.

[sungam3r]

Only few issues left in 4 milestone https://github.com/graphql-dotnet/graphql-dotnet/milestone/7

[sungam3r]

@Shane32 Let's work on #2307 as part of v4. Also, let's take a look at the existing Issues and select the ones that can be quickly fixed. If this requires backward incompatible changes, then it's easier to make them now than wait for the next major version. Also ping @joemcbride for help with federation-related issues.

[sungam3r]

Probably #2279 #1683 #2263 #2180 #1123

[Shane32]

Now remaining:

• Authorized query fields fail before query directives are evaluated #1683 Authorized query fields fail before query directives are evaluated
• ValidationOnSchemaInitialize is useless, and Validation comments is misleading #2204 ValidationOnSchemaInitialize is useless, and 'Validation' comments are misleading -- either fix or add to Known Issues

[sungam3r]

I suggest that you look through all the current issues and select those that you are interested in fixing before v4 (provided that it does not take long).

[Shane32]

I would really like to reorganize ExecutionStrategy to:

1. consolidate all of the execution code
2. make the methods protected so they can be overridden easily

Since we have made so many changes to the execution strategy and API layout already, we should review this now, rather than in v5.

[Shane32]

I'm looking through the remaining issues. I don't have anything else on my mind that I would like to complete, except perhaps enhancing the complexity analyzer, but that is probably too much work at this point.

[sungam3r]

OK. I go through the issues list starting with the oldest. If I see that the fix does not require much effort, then I do it. And of course I just close issues that are no longer relevant 😄.

[Shane32]

I went through the entire issues list just now. All of the issues in the 4.0 milestone have PRs ready for you to review, I believe, besides #344 . I think we should finish cleanup on the execution strategy and scalars and be done.

[sungam3r]

OK. The review will take a couple of days.

[sungam3r]

Only one issue with the bug label left bug Something isn't working - #2257

[sungam3r]

Current status:

• Update copyright? #2342 waiting for approval from @joemcbride
• Add null support to ScalarGraphType #2333 done?
• Add scalar migration notes & update custom-scalars.md #2330 / Scalar documentation #2357 - scalar documentation - under review
• Further cleanup #2327 ping @Shane32 ?
• wrong depth calculation with fragments  #344 not done - REJECTED for v4

What about #2257 ? The single confirmed bug left. I'm not sure.

[Shane32]

@sungam3r As far as I'm concerned, we can release 4.0 as soon as you can help finish PR #2357 - specifically where the Custom Scalars documentation page describes how to replace a built-in scalar. We should certainly write a test to demonstrate the proposed solution, as it is very possible that people want to (for example) continue to allow integer values for a boolean scalar (which is allowed but not mandatory per spec).

I will propose changes to SchemaTypes to allow a more elegant solution, but if you have a solution for the current codebase, we're good.

[sungam3r]

Today I will work on it.

[sungam3r]

Regarding #2357 see #2357 (comment)

[sungam3r]

+ #2370 ?

[Shane32]

#2370 should be a high priority for sure. I don't know if it needs to hold up v4 release, but go ahead and tag it 4.0.

[Shane32]

Current status of issues holding up v4:

• Add scalar migration notes & update custom-scalars.md #2330 / Scalar documentation #2357 - custom scalar documentation - needs review
• Add documentation for reference types #2370 / Add type mapping documentation #2393 - type mapping documentation - needs review
• Replace scalar after schema initialization #2392 - alt replace scalar method -- need bugfix (to make directives instances virtual) before 4.0 for sure

Non-breaking changes that can be done AFTER 4.0:

• Update copyright? #2342 / Update copyright #2358 - copyright - waiting for approval from @joemcbride
• How to change output of decimal scalar (removing trailing zeros) #2257 - cannot override decimal serialization within System.Text.Json
• Fix NameValidator #2380 - fix NameValidator
• Add default implementation of ParseLiteral #2391 - add default implementation of ParseLiteral
• Fix formatting for AstPrinter value nodes #2379 - fix AstPrinter

I do not plan on making any more breaking changes.

[sungam3r]

Releasing as is without #2342 or wait one day for @joemcbride ?

[sungam3r]

I can review #2379 tonight.

[Shane32]

Releasing as is without #2342 or wait one day for @joemcbride ?

Wait another day is fine.

[Shane32]

If you want to approve #2397, I can release 4.0, ok?

[sungam3r]

I'll review it again after 2-3 hours.

[sungam3r]

#2342 was approved 👍

[sungam3r]

#2380 waiting for comments from spec guys. Not a goal for v4.

[sungam3r]

#2397 approved

[sungam3r]

Let's deal with #2379 first and then release v4.

[sungam3r]

And #2403.

[sungam3r]

I can release 4.0, ok?

I think you may to write a notes for v4 in a such way:

1. Write a short introduction for v4 release. No need to duplicate all issues and PRs that we have done do far.
2. Provide a link to resolved issues and PRs (over 200, I marked all of them with v4 tag some time ago): https://github.com/graphql-dotnet/graphql-dotnet/issues?q=is%3Aclosed+milestone%3A4.0
3. Provide a link to migration page.
4. Provide a link to updated documentation. It is just http://graphql-dotnet.github.io but it's worth it.

[Shane32]

Draft release text

@sungam3r I listed the new features in no particular order. Feel free to update this and specifically write a little more about the applied directives feature that was added, in addition to anything else I missed.

See below draft:

Version 4.0

New features:

• Enhanced performance - Executes queries 50% to 100% faster; builds schemas 20x faster
• Reduced memory requirements - as much as 75% less memory allocated per query executed
• Optional query caching service to cache document parsing and validation
• Custom deserializers can be written for GraphQL input objects
• Enhanced custom scalar support, including the ability to replace a built-in scalar
• Stricter type checking on scalars, both when read as variables or when being serialized
• Many bugs and feature requests related to scalars and variable parsing were resolved
• Applied directives
• Dependency injection extensions for the MS DI provider
• Extensive reorganization and clean-up of project internals, while retaining ability to customize behavior as desired
• Better support for validation rules that depend on directives or variable values
• Better documentation, including most of the public members now having xml comments
• Maintains target of .NET Standard 2.0; tested against .NET Framework 4.8, .NET Core 2.1, 3.1, and 5.0

See migration guide here:

• https://graphql-dotnet.github.io/docs/migrations/migration4

See main documentation here:

• https://graphql-dotnet.github.io/

See list of resolved issues and merged PRs for 4.0:

• https://github.com/graphql-dotnet/graphql-dotnet/issues?q=is%3Aclosed+milestone%3A4.0
• https://github.com/graphql-dotnet/graphql-dotnet/pulls?q=is%3Apr+is%3Aclosed+milestone%3A4.0

[sungam3r]

Only one issue left - #2379.

[sungam3r]

EVERYTHING IS DONE!

[Shane32]

master was merged into develop. master3 was created from master. master was then fast-forwarded to be same as develop. master was released as 4.0. develop should not be used until we start on 5.0.

[Shane32]

Patches on 3.x should be applied to master3 and released from there. We have tags already but not pointing to the head of master3 since there are a few commits since our most recent 3.x release. I could add master3 to the list of branches to be tested in test-code.yml but I did not.

[sungam3r]

Seems logical.

[Shane32]

Well, our milestone release date (that we set back when 3.0 was released) was listed as 3/15/21. Although we wanted to move it up to February, it seems we happened to hit our original date within 2 days!

[BrokenR3C0RD]

Will v5.0.0 of GraphQL.Server be following soon?

[sungam3r]

Yes.

[Shane32]

@sungam3r Similar to previous versions, 4.1 is listed as 30 days out (4/15) and 5.0 is listed as 6 months out (9/1). We can change as desired of course, but just setting a goal is good.

[sungam3r]

OK