Skip to content
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

Allow user to opt into pre release updates #1017

Open
shanman190 opened this issue Apr 23, 2024 · 4 comments
Open

Allow user to opt into pre release updates #1017

shanman190 opened this issue Apr 23, 2024 · 4 comments

Comments

@shanman190
Copy link
Contributor

Is your feature request related to a problem?
No, it's not.

Which solution do you suggest?
Add a configuration parameter to allow the user to opt into pre release versions.

Which alternative solutions exist?
Manually upgrade by watching the releases directly.

Additional context

@pascalbreuninger
Copy link
Member

@shanman190 thanks for the suggestion. It's definitely a good addition and we've looked into it a while ago. The problem is that I haven't found a solid way of implementing it without a custom update server. It's not that much effort but more than it's probably worth for the few people actually using prerelease versions.

To future readers: If you always want to stay on the bleeding edge please upvote this issue

@shanman190
Copy link
Contributor Author

shanman190 commented Apr 24, 2024

@pascalbreuninger, that's fair.

When I was glancing through it seemed like a user setting that goes into ~/.devpod/config.yaml could be the start of the chain (this could additionally be exposed via the UI). Then when the UI is asking for the releases from the rust API server, it could send over a query parameter indicating a configured user preference or no query parameter at all if not configured (none (disabled), includePrerelease=true (enabled), or includePrerelease=false (disabled)). Then down in https://github.com/loft-sh/devpod/blob/main/desktop%2Fsrc-tauri%2Fsrc%2Fupdates.rs#L233-L238 if the option came over as explicitly as includePrerelease=true, then we'd just include or exclude them as necessary.

@pascalbreuninger
Copy link
Member

@shanman190
I see where you're going and it would make sense but that part is only for the releases display in the UI.
The real update checks are handled by tauri and we just point them to the latest github releases:

"https://github.com/loft-sh/devpod/releases/latest/download/latest.json"

As we're discussing I've stumbled over this issue over in the tauri repo.
We could probably change the endpoint based on a context option like you suggested, restart the app and have it look for new updates via a prerelease URL.

Two uncertainties from my side:

  1. Is there a URL in github to always resolve to the latest prerelease?
  2. Without a custom update server there's no nice way of downgrading, it'll be a manual process again

@shanman190
Copy link
Contributor Author

@pascalbreuninger, ahh, I see. From a GitHub API standpoint, you'd have to list all releases and filter them as there isn't an endpoint to acquire the latest prerelease generically like there is for the latest stable release.

@pascalbreuninger pascalbreuninger added the enhancement New feature or request label Apr 29, 2024
@deniseschannon deniseschannon removed the enhancement New feature or request label May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants