Create and document a versioning and release strategy

[brettdh]

Motivation

The app has two components that we release:

• The app that we publish in Apple/Google app stores
• The over-the-air javascript-only updates that we publish to Expo

We need a strategy for versioning and releasing both of these, which should have the following properties:

• We should be able to start using Conventional Commits and related tooling - e.g. standard-version and its expo plugin - to manage our releases (possibly after some upstream contributions of our own).
  • Alternative tooling would be fine too; these just seem like a good starting point
• From information we track in our commits, we should be able to determine whether the change requires a new app store release
• When we tag a new app store release, further expo bundle updates are published to a matching release channel
  • This ensures that existing users of versions older than the latest don't receive incompatible bundle updates
• An about screen should be added to the app, identifying the app store version and the bundle commit hash
• The version and commit sha should also be included when reporting errors to Sentry
• The app store release process should be automated in CI, based on git tags and branches
• We should be able to separate beta releases from production releases
  • This applies to both app store builds and bundle publishes

Simple approach that should work well:

• Any semver release is a new app store version
• Only major releases require a new expo release channel
• Beta releases are simply new versions with a -beta.N tag, where N is the build number.

Relevant discussion on Expo developer forums

https://forums.expo.io/t/how-to-handle-releases-and-changelogs-with-conventional-commits/42611

Plan of action

• Set up commitlint and commitizen
• Set up standard-version
• Implement Add version bumpers for bare projects expo-community/standard-version-expo#9
• Implement dynamic release channel based on major release version
• Move CI to Github Actions
  • Detox build + tests
  • Unit tests and linting
  • Expo publish
• Implement fastlane-based release in Github Actions
• Write down the strategy, in README.md
• BEFORE MERGING: publish and use fork of standard-version-expo

Scope

• For simplicity, this issue will include implementing the strategy as well as writing it down.
• For this first attempt, I'm going to largely punt on the hard parts - see the unanswered questions in the discussion linked above - unless that discussion yields some obvious and simple next steps.