Release policy and process

While we don't have a super-formal/fully-codified release policy (yet), there are some things that generally have been followed in most of our releases.

Versioning policy

• Version tags are of the form X.Y.Z (eg. 2.3.0). Historically, semver wasn't followed exactly, and there are no immediate plans to shift to it either. We just randomly bump either Y or Z depending on our mood ;) We don't know when we will bump X next, but it must be for the next big thing.
• Developmental versions are prefixed with .dev{x} (eg. 2.3.1.dev2). x is odd during development leading up to a release, and even for pre-releases.

Release process

This is to be executed by the steering council, or release manager(s) chosen the steering council.

Things to do before a release

1. Address all "critical" issues that may block a release.
2. Ask around for changes any contributors want to see in the release.

Doing the release

1. Make a branch called release/[versionname] with one version bump commit.
   • CI runs on this branch. Once it passes, all wheels are uploads onto a release CI drafts automatically.
2. Write the release notes in this draft release. During this time, contributors (who are org members) are free to test out the wheels, help with the notes and give feedback. A checklist useful for testing
   • Make sure the unit tests pass locally
   • Run a couple of examples and games.
3. Make a PR of this branch, and merge it.
4. Click "publish release", CI automatically makes a PyPI release (after the github actions gets approval from the steering council) from all the wheel artifacts on the draft Github release.
5. Make a new PR for the bump to the next development version.
6. Talk about the release!
   • Discord
   • Reddit
   • Twitter
   • Any other such platforms