Tech Spike into chosen release strategy

As per our conversation, we have decided to do the following:

• Split the Mobile App and API into their own repositories
• Use GitHub Releases to create Mobile App builds and artefacts
o Draft Release: Build artefacts and compile release notes
o Publish Release: Deploy artefacts to App Center
• Use Semantic Versioning for Mobile App, controlled via Releases
o When no tag is present, a tag will automatically be generated using a SemVer file for major/minor version, and number of commits to main as patch number
o When a tag is present, overwrite the SemVer file with the tag’s version number

Remaining questions are as follows:
• Can we automatically calculate major/minor versions based off Gitmojis or other methods?
• Can tags be added to existing releases via GitHub Actions?
• How will this strategy handle Mobile App releases to different environments?
e.g. – we have a version of the app that we want in the hands of testers. This means we need to publish the artefacts to App Center using Staging details (URLs, IDS, other infra, etc.). We then need to publish another release based off the same commit with Production details.

This is a release-strategy spike rather than a file-specific change. Start by answering the three open questions in the issue: version calculation, tagging existing releases with GitHub Actions, and staging/production artefacts from the same commit. Done means a documented, validated strategy for repository separation, versioning, and environment-specific releases.