Prepare to the next release

[sungam3r]

I think it is time to release 3.1. We have several new features and bug fixes. I am interested in how this process will take place.

1. How to deal with 3.1.0-preview version ? Need to remove it first, commit to master, publish and then commin 3.2.0-preview?
2. What about tag automation? Are tags set manually now? Perhaps this happens when creating a release.
   
3. Is CI ready to publish stable packages to nuget? What should be done for that?
4. What role does GitHub Packages have in all this process?
5. Is it possible to somehow automate the construction of the release text so that it includes (at least initially) all PRs merged from the previous release?
6. Do we still need AppVeyor/MyGet (maybe a premature question) ?

It seems to me that now we are somewhere in the middle of understanding the whole publishing process. Several versions need to be released before the whole process becomes clear. Let's start moving in that direction. A month has passed since the previous 3.0.0 release and I am absolutely sure that there is no point in delaying for 3.1. In addition, it will demonstrate the dynamics of the development of the project and possibly attract more attention to it. I remember how painful it was for me to see posts about how people switched to using alternatives because they did not see progress here.

If even now there are no answers to all the questions, then it does not matter. We need to answer at least a few to move on.

ping @joemcbride @Shane32

[Shane32]

With permission from @joemcbride I’d like to replace the appveyor workflows with GitHub Action workflows to push the release to nuget. The process will be as follows:

1. Issue release in GitHub with tag matching the desired version. GitHub will automatically override any version number in the source and publish and upload a nuget package with the specified version number
2. Increment the version number in the source for future preview builds.

I would also like to add a GitHub Action that immediately publishes documentation whenever it is updated in the master branch. Alternatively, it can publish automatically when a release is issued.

The existing GitHub Action already demonstrates 95% of this behavior — it compiles and builds the documentation and packages the source into a nuget package with a specific version number. Both are uploaded as artifacts to the workflow.

[Shane32]

I think it is time to release 3.1. We have several new features and bug fixes.

In general, I agree. The deadline we set previously was 10/15 (as can be seen on the milestone list). I think we should patch/fix the following issues first, if possible -- even if a full fix will need to be in 4.0:

• Is it possible to use ListGraphType<CustomType> inside of InputObjectGraphTypes? #1831 Where validation errors are not returned when variables cannot be parsed
• Do not register unused graph types #1887 Where unused scalars are still included in a schema

There are very small fixes and should be included in 3.1. I also thought we were going to work on #1571 (dependency injection), but as we are running out of time, this can go into 3.2.

1. How to deal with 3.1.0-preview version ? Need to remove it first, commit to master, publish and then commin 3.2.0-preview?

For now? Yes. Not if I rewrite the appveyor scripts using GitHub Actions.

2. What about tag automation? Are tags set manually now? Perhaps this happens when creating a [release]

A tag automatically gets created when you create a release (unless you create a release for a pre-existing tag).

3. Is CI ready to publish stable packages to nuget? What should be done for that?

If we want to transition to GitHub Actions, I will need the upload key to be added as a secret. (e.g. NUGET_UPLOAD_KEY) I can do the rest.

4. What role does GitHub Packages have in all this process?

For releases? Nothing. But we certainly will use the existing workflow as a basis for the release workflow.

5. Is it possible to somehow automate the construction of the release text so that it includes (at least initially) all PRs merged from the previous release?

Certainly, but I don't have the time to write the script to accomplish that. For my internal projects, I typically just copy and paste the commit history since the last release, and then clean it up so it looks something like this:

• fix for aliased list arguments (Fix for aliased list arguments #1893)
• bump deps (Bump deps #1892)
• fix check for interface covariance (fix check for interface covariance #1891)
• Publish merged PRs as nuget packages to GitHub Packages (Publish merged PRs as nuget packages to GitHub Packages #1886)
• Fix ui endpoints (Fix default ui endpoints in documentation #1888)

6. Do we still need AppVeyor/MyGet (maybe a premature question) ?

See prior response for AppVeyor. MyGet is no longer required.

A month has passed since the previous 3.0.0 release and I am absolutely sure that there is no point in delaying for 3.1. In addition, it will demonstrate the dynamics of the development of the project and possibly attract more attention to it. I remember how painful it was for me to see posts about how people switched to using alternatives because they did not see progress here.

I agree, although even more important is setting goals and setting a schedule. If people know their merged fixes will be released on such-and-such a day, they can plan for that. And if they see us setting goals and accomplishing them, it will encourage use of this project as an actively developed one, and hopefully attract more developers to join. Personally, I'm a bit disappointed with myself for having been unable to contribute more over the last month.

[sungam3r]

GitHub will automatically override any version number in the source

I still don't understand how this is possible. How does it know how/where the version is stored.

[sungam3r]

So...

1. Do not register unused graph types #1887 - I have to do a review

2. Is it possible to use ListGraphType<CustomType> inside of InputObjectGraphTypes? #1831 - well... I don't know, seems to be a breaking change.

3. Add MS-specific dependency injection extensions #1571 - definitely 3.2

4. For now? Yes. Not if I rewrite the appveyor scripts using GitHub Actions.

Let's do it old way this time and the next time switch to GitHub Actions?

5. A tag automatically gets created when you create a release (unless you create a release for a pre-existing tag).

That is, you will manually make a release on the releases page, copy and edit the commit history, create a release, select a tag (3.1.0 this time). Then a tag will be created in git, and this in turn will serve as a trigger for publishing the package (still to MyGet I think)?

6. If we want to transition to GitHub Actions, I will need the upload key to be added as a secret. (e.g. NUGET_UPLOAD_KEY) I can do the rest.

Perhaps you should ask @joemcbride about it to move on with GitHub Actions configuration (new issue?).

7. For releases? Nothing. But we certainly will use the existing workflow as a basis for the release workflow.

That is, for now, we are just evaluating where it might be useful to us.

8. Certainly, but I don't have the time to write the script to accomplish that. For my internal projects, I typically just copy and paste the commit history.

Will you do that (copy-paste-format) for 3.1?

9. See prior response for AppVeyor. MyGet is no longer required.

As I understand that at least for the 3.1 release everything remains as it is regarding MyGet. But in the next 3.2 release, we can try to do without it.

So for me the main interest now is to see how creating a release triggers the package publication.

[sungam3r]

Personally, I'm a bit disappointed with myself for having been unable to contribute more over the last month.

Likewise. If I didn't have to sleep, work, take care of the child, family and household chores, then the development of the project would go much better.

[Shane32]

GitHub will automatically override any version number in the source

I still don't understand how this is possible. How does it know how/where the version is stored.

The version number is stored in the project properties VersionPrefix, VersionSuffix, and/or Version. If Version is specified, it overrides VersionPrefix and VersionSuffix. If not, VersionPrefix and VersionSuffix are combined with a dash (-) to form the version number. See: https://andrewlock.net/version-vs-versionsuffix-vs-packageversion-what-do-they-all-mean/

The Directory.Build.props file contains properties that apply to all of the projects in child folders. See: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2019

In the src folder, there exists a Directory.Build.props file containing a VersionPrefix setting. See: https://github.com/graphql-dotnet/graphql-dotnet/blob/master/src/Directory.Build.props None of the csproj files have a VersionPrefix, VersionSuffix or Version setting.

Finally, during dotnet build or dotnet pack you can specify a MSBuild property which will override any property found in the csproj or Directory.Build.props file. See: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-build

In addition to its options, the dotnet build command accepts MSBuild options, such as -p for setting properties or -l to define a logger. For more information about these options, see the MSBuild Command-Line Reference. Or you can also use the dotnet msbuild command.

You can see this in the GitHub Action workflow where this is written (which adds a suffix to the version number):

dotnet build --no-restore -c Release -p:NoWarn=CS1591 -p:VersionSuffix=$GITHUB_RUN_NUMBER

Or you can test building a nuget package with a specified version number with a command like this (execute from the src folder):

dotnet pack -p:Version=3.2.0 -o out

You can see a sample of how a GitHub Action is configured for a workflow which executes upon creating a release here:

https://github.com/graphql-dotnet/server/blob/bc15956a70ddae0f78350c5a6937fb5ff39bb39f/.github/workflows/publish.yml

Within the above file, you can see it pulling the tag from the github.ref property, stripping off the refs/tags/ prefix, saving the resulting tag (version number) in the github_ref environment variable, and finally build and packing the project with that specified version number by passing it as a MSBuild Version property to dotnet build and dotnet pack.

[Shane32]

Will you do that (copy-paste-format) for 3.1?

Sure

[sungam3r]

I have just deleted AppVeyor web hook. So... is this adventure over?