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

Autoupdater #36

Open
adigyran opened this issue Aug 23, 2021 · 11 comments
Open

Autoupdater #36

adigyran opened this issue Aug 23, 2021 · 11 comments
Assignees
Labels
Priority: Normal The default priority Type: Enhancement Adds or improves a feature
Milestone

Comments

@adigyran
Copy link
Member

Implement some sort of auto updater to server, for easy distribution

@Eirenliel
Copy link
Member

Server autoupdate

@loucass003
Copy link
Member

What are the main ideas for this?

Should also only the server updates itself. Or should it also update the new GUI with it ?
Maybe both could have their own self-update cycle separatly ?

@Eirenliel
Copy link
Member

it should be one thing along with the driver

@loucass003
Copy link
Member

So Driver Server Gui ? Or only Driver Server ?

@Eirenliel
Copy link
Member

everything. also overlay.

@Eirenliel
Copy link
Member

and the feeder if it's still separate from the overlay when it's ready.

@loucass003
Copy link
Member

What is you reasoning behind this ? Because i think having separate updates could be pretty usefull. Like being able to update the gui without he server or the overlay without the server

@Eirenliel
Copy link
Member

Eh, it's basic usability? Don't forget that end-user is not a DIY person who wants everything configured and run multiple versions of everything. One update process should update everything there is to update.

@TheDevMinerTV
Copy link
Member

Also remember that would have to insure that the protocol between all the applications is backwards compatible, otherwise this would be a pain in the butt to use.

@Eirenliel
Copy link
Member

Why would it be a problem, all things should be updated simultaneously with this.

@TheButlah TheButlah added the Status: Unlabeled A maintainer has not yet labeled this label Oct 5, 2022
@Erimelowo Erimelowo added Type: Feature Request Priority: Normal The default priority and removed Status: Unlabeled A maintainer has not yet labeled this labels Oct 6, 2022
loucass003 added a commit that referenced this issue Nov 19, 2022
Revert "chore: npm -> yarn (#34)"

This reverts commit 0d4e29b.
@TheButlah
Copy link
Contributor

TheButlah commented Feb 12, 2023

I will attempt to tackle this - I'll be starting by building a cli tool to install the overlay. I'll be modeling it after rustup, where it manages a set of components with versions, and we have channels (like stable) that dictate the versions for each component.

The existing MSI installer will call into the CLI, so we retain the nice UX of the installer while removing the need for so much windows-specific msi scripting. This also gives the advantage of having the same installation logic on windows, mac, and linux, and the ability for automated installation scripts on linux distros.

Likewise, the server and/or gui can initiate a call to the cli tool to ask it to update slimevr. We can choose whether to do this at start always (like discord), or prompt the user first (like signal).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Normal The default priority Type: Enhancement Adds or improves a feature
Development

No branches or pull requests

6 participants