To start of, I want to say that I absolutely love what nextcloud (the company) has built and the software is great.
However, as someone who administrates a larger installation with a bunch of Apps and customization to the docker containers, the inconsistency of changelogs for the apps is driving me absolutely insane.
As I use various apps that depend on additional binaries or services, it is crucial for me to check the changes before updating anything. Some Apps are great with this and the changelogs are directly visible in the admin UI. But a lot of times I have to go to the github repositories to check the releases. Some of those donât even have them on the main/master branch, so Iâll also have to hunt down the correct branch.
I have sympathies for smaller developers that donât want to have the additional overhead of managing some potentially obscure changelog system (I havenât checked how exactly it is implemented). But some of the worst offenders are official Apps coming from nextcloud themselves.
For an example: About a month ago I updated the âNextcloud Officeâ app. Itâs not developed by nextcloud themselve (as far as I can tell), but is endorsed by them front and center as one of the biggest features of nextcloud. Not only does it not show the changelogs in the UI, when I go to the Github repository via the âreport a problemâ link, I end up in the nextcloud/richdocuments repository that (at the time of the update) didnât even contain the new release. Only after some more digging via the external app store site, I found out that the package is actually being hosted on the nextcloud-releases/richdocuments repository.
Today I had the same problem with the fulltextsearch elasticsearch App. Here the latest release in the nextcloud/fulltextsearch_elasticsearch github repo is currently 29 months old.
So please nextcloud, find a way to make the changelog easily accessible. It could even be as simple as providing a link to the actual release on github in the UI. Or as it seems that all packages are distributed this way, just pull the release notes from there as a fallback method.
Did you try â nc-apps â . That is a commandline appstore browser, providing much more information and search features as any other Appstore Interface.
Your example with âNextcloud Officeâ and ârichdocumentsâ which are basically the same (the first is the App-name while the latter is the App-id) ilustrates perfectly why I wrote nc-apps, because I was confronted with exactly the same cases, where the app names and app IDs lead to confusion and to get a quick overview of compatible apps with all available links to the repos and issue trackers.
The only difference between us two, is that I created a solution instead of ranting
I was not yet aware of your script and will definitely give it a try.
I am aware of the difference in the Apps Names and their IDs. thatâs why I made sure to specify when I was referencing the actual GitHub repositories.
Fair enough. However it is my opinion, that the core features (which for me includes the management of officially supported apps/extensions/etc.) of an application that is developed by a company and (also) sold as an enterprise system should work without such annoyances.
So while Iâm thankful for any additional tools that can help deal with this (and I also managed to find the information I needed after some digging), I think that this should be addressed nonetheless.
However, as someone who administrates a larger installation with a bunch of Apps and customization to the docker containers, the inconsistency of changelogs for the apps is driving me absolutely insane.
I agree it can be better. Some of the apps are farther along in this regard than others. There are essentially three camps:
in-repo CHANGELOG.md is maintained (this flows through to the Changelog tab in the app store automatically)
e.g. richdocuments
Release notes are posted with the tagged release (these donât flow through to the Changelog tab in the app store unfortunately, but theyâre always available under Releases/Tags in-repo)
e.g. groupfolders
ârefer to the the commit historyâ (these donât flow through to the Changelog tab in the app store unfortunately)
Category one already meet your preferences (I believe). Category two could easily since itâs all there, but the transition needs to be made to start placing it into the CHANGELOG.md so the app store will pick up the contents. Category three needs some work surrounding the release process.
FYI, Iâm seeing a changelog for Nextcloud Office in the app store:
when I go to the Github repository via the âreport a problemâ link, I end up in the nextcloud/richdocuments repository that (at the time of the update) didnât even contain the new release.
Some apps donât have release artifacts posted in their repos because theyâre not officially distributed from there (but via nextcloud-releases as you discovered), but there is always a branch or tag associated with a release within the repo itself containing the source code for the release. Depending on how backports are handled within a given app, you may have to switch branches or tags.
Itâs not developed by nextcloud themselve (as far as I can tell), but is endorsed by them front and center as one of the biggest features of nextcloud.
Nextcloud Office / richdocuments (note: notrichdocumentscode) is maintained directly as part of the Nextcloud project. Itâs the integration app that connects with Collabora Online (which is separate).
This section could also be expanded to Apps like the Fulltextsearch Elasticsearch Integration. Here there is a repo in nextcloud-releases that gets tracked for the latest versions and a repo in nextcloud which gets polled for the changelog. However as the second repo has separate branches per nextcloud version, the changelog canât be fetched by nextcloud as it seems to expect them in the master branch.
Yes, thatâs what Iâm seeing to. However the changelog here also gets pulled from the nextcloud/richdocuments repo instead of nextcloud-releases/richdocuments repo. For âNextcloud Officeâ that is not a huge problem, but there is still a time-frame of up to a few days between the nextcloud-releases repo being updated and the nextcloud repo being synced. And for this time-frame there are no changelogs visible in the app store either.
(There are others in Featured that donât have their own changelog, but theyâre shipped apps so they only get updated along with Server itself so their changelog entries flow through Serverâs not the app store).
Hmm. The app store pulls the changelog from the CHANGELOG.md in the published artifact when itâs uploaded to the app store. It doesnât look at the repos at all AFAIK. Iâm not sure why youâd be seeing that. Iâll try to keep a closer look out to see if thereâs a mismatch in the cadence because maybe something else is going on Iâm overlooking.
As an app dev of the cookbook app, I have looked into the changelog problem as well. In fact, the changelog needs to be packed in the release as CHANGELOG.md file. This is then parsed by the Python based app store (running on apps.nextcloud.com). The corresponding entry from the provided ZIP file (you only provide a URL to the store) is downloaded, extracted and parsed.
So, the problem might be that the file is not correctly build/packaged/provided on the tarball. The repos (be it in the nextcloud or the nextcloud-releases organization) are not queried about the changelogs in detail.
BTW: The reason for the separation of the repos is simply security. If it was one organization, anyone with writing access could file a PR that would allow to extract the secrets from the repo. By moving the release process to a foreign repository with only limited community access, the attack surface just got factors smaller.
Thanks for the clarification. It seems that my assumptions about the source of the changelog were wrong.
Which makes the fact this is even a problem for officially endorsed apps that much more infuriating to me. (Again, I donât want to hate on small/hobby devs. But at least the ones coming from nextcloud and their partners should not have such problems.)
To be clear, Iâm not criticizing the double repos. I was confident that there must be a good reason for this setup and I thank you for explaining the actual purpose of it to me.
Itâs the fact I need to go hunting for the changelogs in the first place thatâs annoying me. The double repos wouldnât be annoying me if the problem didnât exist in the first place.
