Document release process

[bartelink]

We use minver, which derives versions from tags
When a build is triggered (based on a refs/branches/X or refs/tags/X), the newest tag encountered in that branch dictates the name
As long as you push the tag first, a random PR or branch CI build will pick up the correct version
Before releasing, sanity check the artifacts includes nupkg files with the release numbers you anticipated
the Release button (if you are in the relevant Pipelines org), then sends those artifacts to nuget.org
After that, it should show on the nuget landing page per artifact
subsequent to this (you'll see a message on the package nuget page before its indexed), it'll be indexed in 3-30 mins
when the indexing has completed, nuget update checks will pick up the new version

once a tag has been pushed, from which the build will pick up the version, the github Releases tab is used to add release notes (no automation at present, would be delighted to have a PR with support for some as long as it does not pull in a boatload of dependencies)

Nuget conventions/tricks/hacks esp when adding new packages:

• packages should be owned by jet.com, but for safety the pipelines api keys for a release pipeline should only allow uploads of new versions of existing packages, thus the process for when a new package is added is:
  0. never try to upload if there's a new package in the artifacts as it'll mean a partial upload with associated mess (and no clean way to remediate aside from doing manual uploads of all packages after the first one in the upload order)
  1. manual upload using your mouse on nuget.org
  2. invite jet.com as owner
  3. when accepted, run the release with a new version (noting step 0)
  4. remove yourself as the owner of the new packages