Inform users about a new release

I think it is good to let the user know that a new version is available in the UI.
This mechanism should be disabled by a flag. If you run LeafWiki in an airgapped environment it should not check automatically for updates.
The plan is not to update it, but at least to inform the user that a new version is available.

@Hugo-Galley

@Hugo-Galley - Would you like to take something like this? - At the beginning just the backend part in go?
We already have a config endpoint. We could add in the config that the check is enabled or disabled this should be configurable via ENVs/args. (Something like --disable-update-info)
The config endpoint also requries the current version. This will help us later to identify issues in a specific version.

Maybe you could suggest how we get the current version into the image.

One way could be how I have done it during the build to embed the frontend:

// EmbedFrontend is a flag to enable or disable embedding the frontend
// This is useful for testing purposes, where we might not want to embed the frontend
// During build time, we can set this to false to disable embedding the frontend
var EmbedFrontend = "false"

RUN go build \
  -ldflags="-s -w -X github.com/perber/wiki/internal/http.EmbedFrontend=true -X github.com/perber/wiki/internal/http.EnableCors=false -X github.com/perber/wiki/internal/http.Environment=production" \
  -o /out/${OUTPUT} ./cmd/leafwiki/main.go

Let me know what you are thinking. It is not urgent.

@perber

@perber So if I understand correctly, the idea would be for the application to know its own version number, and when a new update is available, an Update button would appear, allowing us to update the app while keeping our current data?

As for Go, I’ve never worked with it before, so I’m not sure I’m the most qualified person for that part.
That said, I really like the idea, I was actually planning to open an issue about this myself :D

I’m definitely open to discussing it further and happy to help brainstorm how we could make it happen.

Sounds. Good. I think at the beginning we just show the user that a new release is existing. We shouldn't update it at least not in this version. I will prepare something the upcoming days and we can discuss it in the issue here?

What do you think?

@perber

@perber Yes, of course, we can discuss it here.
I think what could be done is to store the currently running version in a variable, and then, at regular intervals (every week? every two days? or maybe a user-configurable option), check whether the version we have matches the tag of the latest release on the Hub.

That could probably be handled in Go, I suppose — something to explore, maybe using cron jobs.

I’m not sure if that’s how you see it — is it?
Otherwise, how do you envision it?

I think the check if a new version is available can be implemented with a simple endpoint in go. (Just retrieving the last version from github)
When the frontend is opened it will call the internal endpoint / which is just a wrapper to avoid CORS issues. (In the frontend we ca add something which is checking every 3 hours or so if a new version is available. If someone has LeafWiki all the time open.)

The frontend can then call the config endpoint. Which holds the current version & our internal wrapper for the request to github.

That sounds good to me. Our two ideas are quite similar at their core. When it’s ready, I’ll be happy to discuss it with you.

You’re planning to develop it for the next release, if I understood correctly — version 0.4.10?

Yes, but we can move it further away. It is not urgent. Currently I'm focusing more on the e2e tests. I added it to the milestone for visibility. The next release is planned for the 28th of November.

Yes, exactly — it’s not urgent. It’s a great feature, but indeed, the UI/UX will be what’s most visible to the user. You’re right.

@Hugo-Galley

Hey @Hugo-Galley,

let me know if this helps you to implement the backend part of it.

In the printUsage() section, please add the description for the new flag and the corresponding ENV variable
→ main.go#L13
It should be an opt-out flag like --disable-update-check.
Add the new variable and the ENV here
→ main.go#L47
Pass the flag here
→ router.go#L29
(If you like, you could refactor this into a small RouterConfig struct.)
Make sure to pass both the flag value and the current version to the router here.
Add a simple new endpoint to retrieve the latest release version from GitHub —
something like /get-last-release would be perfect. You can take a look at the config endpoint. I think this should be enough.
(Keep it simple and straightforward.)

The frontend part is out of scope for now — I might create another card later to implement these changes on the UI side.

@perber

@perber I think there was a bit of a misunderstanding 😅
I thought you were the one working on that part and just wanted some external feedback.
Unfortunately, I can’t take care of that part myself since I don’t know anything about Go.
So I’ll leave this issue to you — sorry for the confusion!

Ah ok... :D ... No worries. I will do that.

I will remove this one from the milestone. I think it is a bit to early atm.

Navigation Menu

Repository navigation

Inform users about a new release #304

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Inform users about a new release #304

Description

Activity

perber commented on Nov 10, 2025

Hugo-Galley commented on Nov 10, 2025

perber commented on Nov 10, 2025

Hugo-Galley commented on Nov 10, 2025

perber commented on Nov 10, 2025

Hugo-Galley commented on Nov 10, 2025

Hugo-Galley commented on Nov 10, 2025

perber commented on Nov 10, 2025

Hugo-Galley commented on Nov 10, 2025

perber commented on Nov 11, 2025

Hugo-Galley commented on Nov 11, 2025

perber commented on Nov 11, 2025

perber commented on Nov 15, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions