Open KuraiAndras opened 4 years ago
I'd be willing to maintain a chocolatey installer. It looks like it could download the binaries using the links from the launcher.
Alternatively, based on the fact that Xenko seems to update itself, but uses a versioned launcher, I could add a package for the launcher or even Do both, with the xenko-launcher package installing the launcher, and the xenko package installing the launcher as a dependency and then installing xenko.
I figure that way admins could use chocolatey to trigger updates for developers so that the developer does not have to be present to trigger the update from the launcher.
Any pitfalls seen in that approach?
@digitalcoyote Thanks for your interest in this task!
Some feedback on both approaches and how it could be done.
Approach 1: Package Launcher
Should be straightforward, it's just an executable and a few files, needs to be updated only on new launcher upgrade. However, launcher currently auto-upgrades so this might be good to disable this behavior (with risks that server-side changes and is not compatible automatically -- at least display a warning if update available that some functions might be broken?).
Approach 2: Package Xenko itself
Idea here would be to create a Chocolatey package for each Xenko version, without relying on launcher.
Xenko itself doesn't have auto-upgrade and it should be fine to stick with a specific old version (as opposed to launcher).
Xenko is currently packaged with many nuget packages, and installing those NuGet packages is needed for actual project compilation. So, it would be best to download it directly in this format to avoid a second download later.
Here's a few possibilities I can think of:
(1) If Chocolatey can reference NuGet package, Chocolatey package could just reference Xenko.GameStudio
nuget package (so that it gets installed as a nuget package) and launch the executable inside.
(2) Otherwise, it could be a little bit bigger bootstrapper that downloads Xenko.GameStudio
package and then launch the executable inside.
Does that seem feasible? Note that both approach are what the current launcher is doing, so it shouldn't be hard to reuse/copy some of its code.
Let me know what you think.
I took a look into how the launcher works (and updates itself). I think putting the launcher on chocolatey is a bit pointless based on how it installs software. That being said, I think I can build a xenko package that installs/updates in a way that will work with the launcher.
This seems like it might be the best approach. It allows the flexibility of the launcher while potentially allowing a team to manage a specific version.
I have a working package for the game engine itself that appears to be be compatible with the launcher (actually requires the launcher to work). Unfortunately, there is a rejected package from 2017 so I'll have to go through the steps to take over the package before I can publish this.
Good to hear, looking forward to it!
I've started the process of moving Xenko's Chocolatey package to Stride3D. How seemless is the upgrade path for users who are not using Chocolatey? (I'm expecting them to initially upgrade through the launcher when the name switch takes place)
Deprecated Xenko package Stride3D Package
EDIT: If this should work, I think this can be closed.
Let Xenko installable from chocolatey. Chocolatey is a CLI based package manager program for windows (much like apt-get). It would give developers another option for downloading your software, as the chocolatey community is growing, and although this is not a necessary feature, it certainly be nice to have.
Chocolatey package creation guide : https://chocolatey.org/docs/create-packages