-
Notifications
You must be signed in to change notification settings - Fork 1
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
Deployment strategy #17
Labels
needs-clarification
Features or bugs that need further clarification and should be discussed.
planned-feature
A feature that was planned and committed to by the maintainers
size-4
Comments
maybe also consider scoop 🤷♀️ |
some nodes
|
formatieren geht anscheinend nicht :) |
5 tasks
We have apt get and portal download as installation methods right now. #73 Do we also want to add a windows/macos package manager? |
I just thought of the possibility to use Flatpack to distribute the Launcher on Linux - might be a nice way to also reach less popular distributions without additional effort :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
needs-clarification
Features or bugs that need further clarification and should be discussed.
planned-feature
A feature that was planned and committed to by the maintainers
size-4
User story
As a user of the Middleware Launcher, I want to be able to deploy it as simply as possible, so that I don't waste time installing dependencies.
Context
Version 1 of the Launcher only allows "manual" deployment by extracting a zip-file that can be downloaded from the Portal. While this is a very easy installation approach, it also has some disadvantages (e.g. the classic .NET framework needs to be installed on the host).
With .NET 6 and modern deployment methods, we have several alternatives to this, e.g.:
Single file deployments: Instead of downloading a
.zip
file with 100 included files that has a dependency to the correct version of the .NET framework, we could generate a single.exe
file that already contains the relevant bits of the framework and has no external dependencies at all. A potential disadvantage of this approach is that this.exe
would be platform-specific.Package manager deployments: We could also make use of standard package managers that come with most modern OSs now, including Windows. Examples to consider:
The obvious disadvantage of this approach is that there are many different package managers that we'd need to automate. Automatic updates could be a big advantage.
The text was updated successfully, but these errors were encountered: