Add beta release capability

[smallketchup82]

Prerequisites

• https://github.com/ppy/osu/pull/30706

Relevant discussion: https://github.com/ppy/osu/discussions/29140

Morale

Following the recent issues with the Linux release, it seems clear that implementing beta releases could greatly benefit Lazer. This is especially relevant given the substantial growth of Lazer's player base over the past year. Today, more users than ever depend on stable, reliable releases.

Historically, Lazer's release schedule followed a bi-weekly schedule, which has since shifted to a monthly schedule to prioritize larger, more comprehensive updates. Introducing beta releases on a bi-weekly basis could bridge the gap between these updates, targeting users who are open to encountering potential issues and eager to test new features.

Additionally, beta releases could act as a testing ground for significant, non-gameplay-changing features. For example, features like the new song selection interface (when available), SDL3 integration, or other experimental technologies could be introduced and refined within the beta stream before becoming part of the default steam.

I believe a beta release system has significant potential and strongly encourage its consideration. It could contribute to greater release stability while fostering closer collaboration between developers and the community. For users interested in contributing to Lazer's development without the necessary programming expertise, beta testing offers a meaningful way to get involved.

Notes

• I have decided to name Lazer's beta release stream "Photon," aligning with the existing naming scheme. Lazer was named to signify its position as a complete remake of the osu! client from the ground up—more cutting-edge than "cutting edge," since it represents an entirely new foundation compared to the stable client. Similarly, "Photon" reflects this progression, taking it a level further, as it is even more cutting-edge than Lazer itself. However, I am open to reverting to a more generic "beta" designation if that is preferred.
• Several questions remain unanswered, such as whether beta releases will be ranked, if access will be restricted to osu! supporters (similar to the stable cutting-edge stream), and other related concerns. As a result, I am opening this as a draft to encourage discussion.
• I've recently reinstalled my operating system, and didn't include my virtual machines in my backups due to their storage requirements. As a result I lack a proper multiplatform testing environment at the moment, and it can take me a couple of days to set it up again to be able to properly test this. Which is another reason why I am opening this PR as a draft. I'll update the checklist below once I have my testing environment set up again.

Testing Checklist

• [ ] Set up testing environment
• [ ] Test for any regressions in the standard updating procedure
• [ ] Test creating beta release
• [ ] Test switching between release streams

[peppy]

Does this work with the github "pre-release" parameter? The hardest part of making this work is going to be the deployment setup with github actions and our existing flows for changelog / change notes generation.

[smallketchup82]

The way I have it set up right now is that a configuration value in App.config is flipped to indicate a beta release, although I can change this to a CLI positional argument if needed. Looking at the help for vpk upload github:

Description:
  Upload releases to a GitHub repository.  

Usage:
  vpk upload github [options]  

Options:
  -o, --outputDir <DIR> (REQ)  Output directory for created packages. [default: Releases]                               
  -c, --channel <NAME>         The channel to use for this release. [default: linux]                                  
  --repoUrl (REQ)              Full url to the github repository (eg. 'https://github.com/myname/myrepo').             
  --token                      OAuth token to use as login credentials.         
  --publish                    Create and publish instead of leaving as draft.                                           
  --pre                        Create as pre-release instead of stable.         
  --merge                      Allow merging this upload with an existing release.                                         
  --releaseName <NAME>         A custom name for the release.                   
  --tag <NAME>                 A custom tag for the release.                    
  --targetCommitish <NAME>     A commitish value for tag (branch or commit SHA).                                          

There looks to be a --pre argument which would upload the release to github and mark it as a pre-release. I can add some logic to automatically add this argument if publishing as a beta release. This should be what you're looking for.

Github seems to offer an API endpoint for creating release notes we could possibly tap into for automating changelogs via CI.