New version notification should depend on installation type: docker or native

[24mu13]

The server should notify a new available version depending on the installation type:

• Native: if you manually installed NC it's fine like it is
• Docker: if you used Docker you should be notified about a new version ONLY if the image has been already published in the registry.

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

[szaimen]

• Docker: if you used Docker you should be notified about a new version ONLY if the image has been already published in the registry.

Isnt this already done by removing the updatenotification app from the image?

Or is this issue about improving the updatenotification app?

[byquanton]

I guess it is about improving the update notification app,

[24mu13]

Sorry I didn't know about notification app: so yes, I am proposing to improve it being able to distinguish normal installation from Docker one. In fact, when installed by Docker you have to wait up to 2-3 weeks before having the image ready on the registry. But still, I think is useful to be notified about new version release..

[szaimen]

Just FYI, Nextcloud AIO has such a feature already implemented from the beginning: https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-often-are-update-notifications-sent

[kesselb]

I don't think it's on the roadmap to extend the updatenotification app to query other sources for new versions.

Wouldn't docker users rather use something like watchtower to get notification about container updates?

In the case it's probably easier to disable the updatenotification app.

[kesselb]

In the case it's probably easier to disable the updatenotification app.

Apparently, this will also remove the notification about app updates.

I think a configuration option, via app config, to disable the server update check would be acceptable.
Moreover, there should be a help text explaining that the updater check is disabled.

[joshtrichards]

if you used Docker you should be notified about a new version ONLY if the image has been already published in the registry.

There's also the complication that there are numerous Docker images. We don't control the various images people use nor their update publishing timelines/policies.

[nazar-pc]

Sure, but it'd be great to at least cover the official ones. I am subscribed to Atom feed of Nextcloud releases, but I can't update my installations in time because container images are published days or weeks later and it shouldn't really take that much time to get them out of the door.

[rubo77]

A quick enhancement would be to delay the update notification on docker containers for a set period (e.g., 48 hours) after the release, allowing time for Docker images to be published. Maybe through a new config variable delay_update_notifications

[kesselb]

A quick enhancement would be to delay the update notification on docker containers for a set period (e.g., 48 hours) after the release, allowing time for Docker images to be published.

No, because the time varies.

[major-mayer]

Yeah, especially if you are on the stable Nextcloud images it can take weeks until the stable tag gets bumped as well.
So I think this wouldn't really improve the situation.

Maybe a dedicated app which checks for updates in the Docker registry and allows you to specify the image that you are using, would make sense.
But then, you could also switch to something like Watchtower etc. and enjoy automatic updates.

[joshtrichards]

There's some additional spec work for changing how updatenotification presents things (it's responsible for not just notifications but the screen you see in the Admin settings->Overview spot). See #45402.

Another possibility that I've kicked around, for the packagers (all Docker images, Snap, Distro packages, etc.), is creating a sort of base (skeleton) app that can then easily be extended for each package's approach to updates (and, where desired, even tied into their update mechanism). In this way, each package method could (if they opted to) distribute an app for handling this sort of thing, but without reinventing 80% of the wheel each time.