Beta for Lazer?

[Tenexxt]

Beta is avaible for stable as an supporter feature, but since stable doesn't get new updates, atleast with new features, it would make more sense for the beta test to be open for lazer instead, or both simultaneously. Personally tho, i think closing beta for stable would make more sense, since as of now, there weren't any updates for it since may, and those were QoL changes only too, but lazer gets new features and tons of updates, so it would make more sense personaly, and it would allow for less bugs to be out on the final relases of the updates.

[Stoppedpuma]

Lazer is planned as a release stream inside of stable. Additionally you can expect release streams in lazer eventually.

[smallketchup82]

My PR that migrates lazer to velopack allows us to utilize different release streams. I also brought up the idea of having a release stream based on the latest git master branch (using builds provided by github actions) in my pull request.

But this would more or less break semantic versioning, and would require additional support from upstream Velopack. Not only that, but it'd be exceptionally risky since a rewrite of git history could cause problems. And you also have the issue of realm migration & versions (though this could be fixed by having such a release stream backup the realm database before every update). Oh and it'd almost definitely be unranked.

it would allow for less bugs to be out on the final relases of the updates.

In my opinion, upstream Velopack implementing staged rollouts would help with this a lot more than having another release stream for lazer.

The risk of having users on such a stream could outweigh the benefits of allowing it. Because of that, I don't believe we'd see such a feature unless a good amount of users ask for it. But I'll still CC @caesay to gather his thoughts on this (since I didn't really discuss it at all apart from a simple mention of it)

[caesay]

I'm only commenting because you cc'd me, but I don't really have anything to add here. Yes, Velopack supports release streams (channels), it enables users to switch between channels (so your users could use the UI to choose whether they wish to receive bleeding edge updates), and it also allows you to retract releases and have users upgrade backwards! (downgrade). So feel free to use these features in the way that makes the most sense for the project.

[smallketchup82]

I was asking more about your thoughts on breaking semantic versioning.

My main concern with this feature would be: If we were supplying builds from latest git master, we wouldn't have a semantic version for it, we'd only be able to identify the version by the commit hash. Could velopack support tracking commit hashes to allow a feature like this, instead of having to have github actions bump an imaginary number to use as a version for each commit?

[caesay]

A commit hash does not have any intrinsic order. It's basically just random letters and numbers. If I gave you 1.0.0-2ffc38 and 1.0.0-ed21e2 could you tell me which is the latest?

I think most people do something like 1.0.0-alpha.1 and 1.0.0-alpha.2, and Velopack will support that just fine. You can use nbgv https://github.com/dotnet/Nerdbank.GitVersioning to automatically bump an arbitrary version part (eg. minor, patch, or tag) on each new commit, I use it to version all of my projects. Bonus is that you can determine the version locally, and not just in ci, because it's just based on the number of commits since the last edit to version.json.

[smallketchup82]

Thanks for the mention of nbgv, we could definitely utilize that if we went the latest git master route.

But upon thinking this further. I can probably engineer it to be more practical:

I'm thinking of making github actions provide a daily build of the latest git master rather than a build immediately when a new commit is pushed to master.

That would allow for semantic versioning (or calver as lazer does it) and would give us a window to pull/revert a commit before that daily build. We can also use github prereleases for this. This, in my eyes, would be a lot more stable and practical. Though, still probably unranked.

I'll probably think this one over some more. If anyone has more thoughts on this, do let me know.

[peppy]

historically with osu!, our versioning has always been date based so we'd be doing something like

2024.728.0-nightly
2024.728.1-beta               // beta stream
2024.729.0-nightly
2024.729.1                    // actual release
2024.730.0-nightly 

Of note, versions will always be unique (we increment the last number for subsequent releases on the same day.

If I'm reading above correctly, this should work just fine?