-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Beta / preview images #6
Comments
you have to pass in a previous version for your selected channel as "buildid" for it to work. it's a diff based system, so you get nothing if you pass the current version. |
And yes we are interested in Beta images, maybe Main too |
Just for posterity I did a bit of digging into how updates are fetched and posted my findings here: #5 (comment) From what I can tell it seems like |
For now we are not planning on producing beta or preview images as an option right now just due to the complexity. If there is further interest expressed then it's definitely possible but it just wouldn't be of much benefit to us right now. |
I realize there may not be a ton of demand for these, as mentioned in #4 (comment) but admittedly, part of the reason I started working on #5 was because I actually wanted to build myself a 3.5 image to start developing in it.
I've gotten a proof of concept building in my fork, and I'm happy to work on upstreaming it if that's something that would be considered useful. There are a couple of considerations I'd like to ask about or at least mention, though:
The package list looks different between different release branches, so there would be some additional maintenance there. Right now I have a
removed-beta.txt
,removed-release.txt
andremoved-packages.txt
(common to both) in my implementation, does that seem like a reasonable approach?Is it worth also having a separate
preview
(orbc
) build? At the moment, it seems like 3.5.0 is the current version for bothbeta
andbc
, so maybe just having a singlebeta
is simpler (at least for the time being)?Does the
variant
for the base image need to besnapshot
? I'm a bit confused overall about how Valve's release process works, from looking around on https://steamdeck-atomupd.steamos.cloud/meta/steamos/amd64/ I have gathered a couple things, but since y'all set up this image maybe you understand / can explain it better:snapshot
represents Arch packages captured at some date in time (date becomes thebuildid
, before the.
?)variant
goes roughly fromsteamdeck-main
->steamdeck-bc
->steamdeck-beta
->steamdeck
. Not sure wheresteamdeck-staging
fits insnapshot
(andbuildid
) may be updated as it travels through the stabilization processdownload.sh
looks forvariant=steamdeck
(stable) packages withversion=snapshot
starting from some basebuildid
to get the most snapshot used for the most latest stable imageDoes that all sound right? For my beta version, I swapped to
variant=steamdeck-beta
but keptversion=snapshot
and the same basebuild
, but in the response the version isn't asnapshot
:compare this to the stable version, which is a
snapshot
:It doesn't seem to be a problem but I was just curious if this looks "correct" based on the build process for the stable versions or not.
Phew, that was a lot more writing than I thought this issue would be! Long story short, if you'll take it, I'm happy to take a stab at building beta packages and opening a PR to implement it. If not, I can probably make do on my fork in the meantime. Thanks!
The text was updated successfully, but these errors were encountered: