mirror of
https://github.com/open-webui/open-webui.git
synced 2026-03-12 10:04:14 -05:00
feat: create releases with ollama-webui version numbers #109
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#109
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @malteneuss on GitHub (Dec 20, 2023).
Is your feature request related to a problem? Please describe.
I would like to package Ollama-WebUI for the NixOS Linux distribution , but missing versions would make it difficult for users to distinguish newer versions from older ones (currently, we only have Git hashes).
Describe the solution you'd like
Create releases or pseudo-releases with version numbers (as frequent as feasible and with whatever breaking changes, changelog or version numbers as you please).
Additional context
NixOS or rather the Nix package manager (available for Mac and other Linux distributions) makes it very easy to get and run the app with a single, short terminal call. It will likely be as follows:
Link to NixOS PR: https://github.com/NixOS/nixpkgs/pull/275448
Btw, thanks for this awesome UI (to me it's the best i found so far for Ollama).
@tjbck commented on GitHub (Dec 27, 2023):
Hi, Thanks for creating this feature request! I'm actively looking into this and I was wondering if you're aware of any ways to somehow automate this? I suppose I could manually create new releases with any changes but that seems suboptimal, Thanks!
@anuraagdjain commented on GitHub (Dec 29, 2023):
We could use the version in
package.jsonand bump that every time a PR is merged to master using GHA. If there was only a change to the backend, in that case too we modify the version as the whole app is packaged together. Also, create a release tag with the same version which could be used for the original issue. Wdyt?@tjbck commented on GitHub (Dec 30, 2023):
@anuraagdjain Thank you for the suggestion, but the version "tracking" is being done from the backend now:
13881beedd/backend/config.py (L34)I've been manually updating the version number from the line above, so I'm not so sure if using the version in
package.jsonwould be the best choice. Any other suggestions? Thanks as always!@anuraagdjain commented on GitHub (Dec 30, 2023):
To avoid manually bumping the version, I recommend something as done in this article https://medium.com/@johnathanmiller/github-actions-npm-version-bump-using-labels-on-pr-merge-8c716a488a64 .
npmcan handle it.Since we've package.json, for above reasons I think its best to use it.
@hemangjoshi37a commented on GitHub (Jan 19, 2024):
I think we should have a feature in which version update notification should be displayed if not running latest version of ollama-webui in settings and update button for downloading latest update should be displayed next to it.
here we can also have a drop down menu to jump to particular version or nightly version that uses latest github code for latest update by pulling latest github repo code . this is what I have mentioned in the #527 but as it is closed I am mentioning here again. thanks .
@oxaronick commented on GitHub (Jan 22, 2024):
@hemangjoshi37a I get where you're coming from, but a button that pulled new code and ran it on the fly wouldn't work for everyone. If that was implemented, there should at least be a setting to disable it, or some auto-detection of
.gitthat enabled it in the first place.As someone deploying this on a server for a dev team to use, I'd rather manage versions through docker version numbers. I wouldn't want to deploy the docker container for v1.2.3 then have someone click a button in the UI that updated the code. Then I'd be running v1.2.4, but if you look at docker it looks like it's v1.2.3.
Another way to look at it is whether or not updates to the web app are the concern of the web app itself. I think notifying of updates in the UI is fine, but actually trying to perform the update from within the web UI is bound not to work for all users.
Just my $.02, to represent the users running it on a server and not just locally.
@hemangjoshi37a commented on GitHub (Jan 25, 2024):
@rcgtnick this can be done in one particular way.
1 pull the latest docker image.
2 delete container id
3 restart the container id of the latest running image.
Also this
upgradebutton can be shown to only those who are running it using docker by detecting how the software is run or how it is installed.@nickthecook commented on GitHub (Jan 25, 2024):
@hemangjoshi37a an app I am running in a container should not have that level of privilege in a production system.
That kind of architecture decision would make this app unsuitable for use outside of a development environment.
@justinh-rahb commented on GitHub (Jan 25, 2024):
I agree with many of the sentiments expressed here. I don't think it's necessary to include an upgrade mechanism within the application itself, as Docker and Kubernetes already provide robust version control through the use of versioned images. While I understand that things are still in a state of flux, I believe that once version 1.0 is ready, it would be appropriate to start tagging Docker images with version numbers.
For now, I am content with periodically pulling the latest image and redeploying my container as needed. This approach aligns with the philosophy of Docker and allows for easy and efficient deployment.
In the future, we can perhaps discuss implementing a version update notification system, but it's crucial that we do not modify running code within a container image. This is not in line with the principles of Docker and could lead to unintended consequences and issues with the application's stability.
@hemangjoshi37a commented on GitHub (Jan 26, 2024):
How can we make a UI that is user-friendly to a dumb person proof? that is by providing dev level control at ease and with great UI/UX , for incorporating this we have to make this button possible. I have noticed in various opensource projects is that they lack UI/UX most of them to say the least. If we can improve upon this then we can beat proprietary App world.
@anuraagdjain commented on GitHub (Jan 28, 2024):
I agree with this sentiment. By showing a small UI and a link to the article showing how to upgrade would be much beneficial than focusing on having the auto update mechanism. Again, it depends on the project maintainer to decide the roadmap so we could help them.
@anuraagdjain commented on GitHub (Jan 28, 2024):
Auto update might be a good thing to bundle if this issue https://github.com/ollama-webui/ollama-webui/issues/470 is going to have more focus.
@Lanhild commented on GitHub (Feb 17, 2024):
Indeed, releases are much needed for pulling the code using version numbers in various workflows.
Using automated releases you could also take advantage of the then newly created release to push the docker image with the same tag version.
@justinh-rahb commented on GitHub (Feb 17, 2024):
All in the plan, Lan. I contributed a modified docker build action that will accomplish exactly this once we start tagging releases. For now, the docker images are at least tagged with the git commit hash that produced them.
@Lanhild commented on GitHub (Feb 21, 2024):
@justinh-rahb
As properly versioned releases are not a thing right now, why not use the git commit hash in an automatic release workflow in the meantime?
@justinh-rahb commented on GitHub (Feb 21, 2024):
@Lanhild I had something like that in mind, ya. What do you think @tjbck do you think we can find a way to replace the build part of the version string with the hash during the docker build?
@Lanhild commented on GitHub (Feb 21, 2024):
@justinh-rahb I've opened https://github.com/open-webui/open-webui/pull/839. That would add an automatic GitHub release workflow that tags releases with the short-form of the commit hash.
The same behavior could easily be adopted in the Docker building workflow.
Regards.
@justinh-rahb commented on GitHub (Feb 22, 2024):
Looks like we got an extra
vsomewhere @tjbck@tjbck commented on GitHub (Feb 22, 2024):
@justinh-rahb #850 should fix it!