Thanks @Romfos .

Was hoping to get some process clarification for this change:

• Previously intermediate builds (between releases) where versioned independently. If testing something with an intermediate build is there a good way to refer to a particular build?
• Does this deprecate tagging in our release procedure? How do we tie a version on nuget to a specific commit?

How to release documentation:

1. Run "Release documentation" build
2. Publish website (built to output dir, bin/Release/nsubstitute.github.com).

How to release nuget package:

1. (no changes here) Move unreleased changes in CHANGELOG to new version heading.
2. (no changes here) Ensure BreakingChanges.txt up to date and move unreleased breaking changes to new version heading.
3. (no changes here) Ensure Acknowledgements up to date.
4. (changed) Make final commit for release. (need to update <Version>x.y.z</Version> inside NSubstitute.csproj in this step)
5. (no changes here) Create release tag and generate release notes
6. (changed) Run "Release packages" build
7. (changed) Publish nuget packages to nuget (need to publish also snupkg)

How to release get packages for internal testing before release to nuget:

1. Just run "Release packages" build and get current packages for current version from main

How to release for "beta\alpha\e.t.c" packages:

1. Use normal release package process but with prerelease version. For example: <Version>6.0.0-beta1</Version>

Defacto we are still using tags as indicator for release commit, single difference is that tags are decoupled from "build" procedure

@dtchepak documentation is updated. PR is ready to be merged. (I don't have merge permission)