Add "Tachyon" (unstable) release stream#33162
Conversation
| private void onReleaseStreamChanged() | ||
| { | ||
| updateManager = new UpdateManager(new GithubSource(@"https://github.com/ppy/osu", null, false), new UpdateOptions | ||
| updateManager = new UpdateManager(new GithubSource(@"https://github.com/ppy/osu", null, releaseStream.Value == ReleaseStream.Tachyon), new UpdateOptions |
There was a problem hiding this comment.
Is this safe? Spawning a new update manager every time the config setting is changed. Won't the old one still continue its processing?
There was a problem hiding this comment.
It probably won't cause any issues but I suppose we can make this a little bit safer.
|
Ignore the close, misclick button. I'd like to add something to ensure that the release stream is restored to Seems the best way may be to set a Line 189 in 75781e3 |
Wouldn't this make installing Tachyon over an existing install change the stream to Lazer? I guess the bigger problem is how does an installed game know if it's from a Lazer or a Tachyon release stream. |
|
I guess setting a build-time flag would make the implementation simpler, for sure. Or even basing this on a suffix in the version string. |
|
This PR avoids using build-time flags or suffixes to not require deploy (including auth) changes, and honestly who knows what else (likely another osu!web release stream too, for instance). We couldn't use the pre-release flag at all because you wouldn't be able to promote a version to the stable stream.
That's fine by me. The releases page is chronologically ordered so I wouldn't want players entering directly into Tachyon in the first place if they happen to accidentally download the pre-release version. |
|
Yeah I'm not too fussed about users downloading the prerelease directly (they probably shouldn't). But I'd still like a user to be able to recover by installing non-prerelease over the top, as I originally mentioned. Are you okay with a |
|
I don't think it needs to be a static on the game class. Can be a static in |
|
I've tested d19e65b in various scenarios and it looks to work as expected. @smoogipoo requesting your re-check on my changes. |
osu.Desktop/Program.cs
Outdated
| app.WithFirstRun(_ => WindowsAssociationManager.InstallAssociations()); | ||
| app.WithFirstRun(_ => | ||
| { | ||
| isFirstRun = true; | ||
| WindowsAssociationManager.InstallAssociations(); | ||
| }); |
There was a problem hiding this comment.
I believe you'll want to put this in the parent method, because as-is this will only run on Windows.
i.e. I think it should be fine to:
app.WithFirstRun(_ => isFirstRun = true);
There was a problem hiding this comment.
I've tested on macOS and it doesn't seem that this code will run on re-"install". Which makes sense since there's no installer.
I guess it is what it is for now and the user will have to switch their release stream.
Supersedes/closes ppy/osu-deploy#183
Supersedes/closes #30706
Inspired by ppy/osu-deploy#183 (comment), this is my take at adding a "Photon" (beta) release stream. Unlike the implementation above, this one only relies on the pre-release flag which I believe to be advantageous:
releases/latestand will continue to link to the latest non-pre-release version.stable/beta/ce), we can decide how to handle it at that point in time. If we want to use the old-style stream naming, then we can also do that.2025-05-16.21-43-11.mp4
Notably, we should do one release prior to deploying any super experimental stuff (Satori GC) so that people have the
Photonsetting in the dropdown.