F* release process

Find volunteers for creating Mac packages. For Windows and Linux use the weekly-build infrastructure. You can trigger such builds any time via Azure DevOps (aka VSTS). Use the FStar-Binaries-Linux and FStar-Binaries-Windows build definitions.
Find volunteers for testing packages on Windows, Mac, and Linux
Make sure that F* builds, passes all the tests, and that creating binary packages works well
(Maybe one day) Close all issues that were already fixed (helps getting nicer release notes, but only works well if people actually use the tracker for their work).
Push all changes to the OCaml snapshot
Bump the version in version.txt
Create a new branch called v0.9.x.y (CH: or a tag, but branch works better in case any problem is discovered and it needs to be updated) For alpha or beta releases use v0.9.x.y-alpha or v0.9.x.y-beta.
Draft a new release on GitHub using the new branch, the version maybe followed by some mnemonic as the release title, and a description of the changes. Can use GitHub for a list of changes between two releases or of issues closed between two dates.

Have the Mac volunteer create package for their platform and add them to the release. For Windows and Linux use the weekly build infrastructure from the first step.
Have the volunteers test the binaries for their platform https://github.com/FStarLang/FStar/blob/master/INSTALL.md#testing-a-binary-package
At the end of a release, please remember to update the links at: https://www.fstar-lang.org/#download

Provide feedback