Use MinVer - #3562

😮 Did you notice that?

https://stackoverflow.com/questions/75537987/how-do-i-get-the-github-actions-section-in-the-visual-studio-solution-view

I don't favor this. First, I don't like having to retrieve the entire commit history, further delaying test runs. But even more importantly, I don't like introducing another build-time dependency when it is not necessary. We already have too many dependencies here that constantly "need" updating. It also makes it more difficult to understand the versioning process by looking at the csproj and workflow files, whereas now it is clear and precise.

What are the benefits? The numbering for dev builds is more "accurate"? Does not matter; they require quite a lot of work to use, and the few users there are (if any) should not care.

So in summary, I see this as something that increases, not decreases, the maintenance and development time required for GraphQL.NET. As an open-source project maintained by only two of us, both of which are extremely pressed for time, I cannot endorse it.

What are the benefits?

The benefits are to rely entirely on tags when calculating the version and not to change it in the source code and/or scripts. Note that we do not always remember to bump version in Directory.Build.props file so it may be like 7.5.0-preview while 7.5.0 release package was already pushed to nuget.org. Not a big deal though, just small automation.

I'm not going to force this PR. I will let it be here opened for a while and will close it if your opinion does not change. In some of my projects I recently switched to MinVer. I like that everything works simply and without my intervention in versioning.

Another option is to leave the version in directory.build.props at 20.0.0-preview. It will always generate a newer version than the latest published version. (This only matters if using another published package like the server project in conjunction with a dev build.)

If I have time perhaps I will test MinVer in one of my own repos

If I would choose between some kind of fictitious version and the absense of version in sources, then I will prefer the latter.

If I have time perhaps I will test MinVer in one of my own repos

👍 Honestly it took me a couple of years to finally try, I have long known about this package and saw its use in other famous repositories.

@Shane32 Did you try? I also worked with gitversion last months. It works well. See https://gitversion.net/docs/.

I think what we have already works perfectly.

I've personally learned to be careful about additional Dependencies. Especially in an Open Source Project, it's also, i think, nicer to use as basic/default of surround-tools as possible. As it makes it easier to contribute for new devs. Especially experienced devs, already comfortable with alot of the Default tooling.
(i.e. I can mostly understand yaml pipelines, from my experience with gitlab and azure devops, and git commands, but would have no idea, off the bat, what MinVer is)
Maybe with this PR being >1 year old, a decision could be made, for the sake of gardening?

I'll close it for now then. We can reopen if we wish to discuss further.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.89%. Comparing base (f087608) to head (a875e87).
⚠️ Report is 484 commits behind head on master.

@@           Coverage Diff           @@
##           master    #3562   +/-   ##
=======================================
  Coverage   83.89%   83.89%           
=======================================
  Files         381      381           
  Lines       16884    16884           
  Branches     2710     2710           
=======================================
  Hits        14164    14164           
  Misses       2073     2073           
  Partials      647      647           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.