Development release process

(NOTE: edit/reorg this information later, I'm just trying to get important things written)

General rules/lessons learned

1. Always work out of your own forked repository, on a branch that is not master (avoid confusion) e.g. rosskevin/feature-xyz
2. Do not release code to the world (unless it is a private tester) that is not merged to openvrmc/OpenVR-MotionCompensation/master and tagged as a release
3. Always create a release on https://github.com/openvrmc/OpenVR-MotionCompensation/releases from your commit when you are ready. You can mark it as a pre-release
4. Release in a timely manner while you are familiar with changes. Familiarity with the change allows one to get it released, and perhaps patched to stability easier than waiting months and forgetting what changed. This is also the reason why PR descriptions are very important (and by propagation release notes)

Merging new code

1. All code is merged to openvrmc/OpenVR-MotionCompensation/master via a PR
2. Create a PR from our user-repo/branch -> openvrmc/OpenVR-MotionCompensation/master.
3. The PR should contain bullet points regarding changes made. These bullet points will likely be suitable as some or all of the release notes when a release is created.
4. A release can consist of one or more PRs
5. Merge PRs quickly if possible to prevent problems for other developers (causing them to rebase). Rebasing is an unavoidable part of mutual development, but smaller, more frequent PRs/changes merged are generally preferable to large ones

Creating a release

1. Use semver to govern release numbering, information and rules here https://semver.org/. This is important as it is a fundamental to communication to a bigger community about stability, changes, etc
2. Always summarize (bullet points) changes in the release page for history
3. Release notes should contain issue links to the PRs that are included
4. Once PRs are merged, click Draft a new release on https://github.com/openvrmc/OpenVR-MotionCompensation/releases
5. Set the version number, and always target master. The only reason not to target master is if you want to release a patch that you would like tracked as a tag and listed in the releases page.
6. Release title should be the same version number
7. Copy bullet points from PRs included into the description, link to the PRs via number
8. Attach the binary build files (compiled exe). The source tarball etc is automatically created at this tag
9. Mark as a pre-release if below 1.0.0 or a tester release
10. Publish