Sometimes an app gets a yunohost only update. The name changes then from appversion~ynh2 to appversion~ynh3.
But where can I easily find the change log for these updates? I could look at github repos and track changes of files, but that seems rather a lot of work.
Is it ever considered to display a change log in the ‘System Update’ interface?
That’s the right way.
Adding a changelog is in fact a lot of work, so it will complicate the maintainer work.
I have added a simple changelog page in the wiki of the package of lychee here
I did it mainly for me to have a clear view what I’ve done so far.
There is something that can be done but it should not make maintaining apps heavy.
true.
The things is; I now look at this possible update:
Nextcloud from 30.0.6~ynh2 to 30.0.6~ynh3
This is a very important app on this server; many users depend on it and nextcloud has gigabytes of data in it and I don’t want to run the risk of needles downtime because something breaks during the upgrade.
So to make a good decision, it would be good to know if this update is adding albanse translation to the readme or fixing a critical security vulnerability.
I wish there was an easy way to find that out
If it’s the case, there is an announcement in the security forum: Security - YunoHost Forum
But i agree with you, a changelog could be useful (the last nextcloud update enable searching of collectives from the unified Nextcloud search).
I second the need for changelogs. And checking which PR have been merged in GitHub is a pain, for the regular user.
As maintainers have to update the manifest, I think the burden to update a changelog file isn’t much work. And helps a great deal the end users IMHO.
I’ve been doing that for Debian packaging and clearly that wasn’t so hard.
In fact it is
Don’t knock yourself out in pursuasive argumentation 
I have no idea how much work it is. But people make updates for apps for a reason. There is no new Nextcloud update for nothing. If the person updating the YNH package at least writes down why it was time for an update (new Nextcloud released, security fix, better integration with YNH etc. etc.) and this is displayed in the update interface… it would be a giant step forward.
To make that change to YNH is probably a lot of work, but writing why you as a packager made an update to an app… shouldn’t be that hard… right?
And in terms of ratio of time spent, it is better if one person (the maintainer) does the work once, instead of each of the many “sysadmins” doing the work in turn, as many times as there are deployments over YNH instances…
This doesn’t have to be mandatory, but the possibility of moving to such a habit (again, already practiced by packagers in Linux distros) would be a great improvement IMHO.
This is still voluntarily done by the packagers, cf. Documentation | Yunohost
So the functionality is there! That is the main thing; now to find a nice flow for packagers to do this.
Hello,
As a maintainer of about ~10 apps I would say that ideally we need to have some automation aroud this to have this deployed in the whole apps. As same as for auto update, auto patch and the update of the readme, we should have something for changelog. It could be by example based on the PR which was merged since the last release or the commit. To me creating a changelog I agree is not a big job but there are a lot of release for some app and it could take at some point an amount of time that I can’t invest for this. Of course, we can’t automate everything, but having a script which create the base automatically and then the packagers can customize it if needed would be really usefull.
Packagers can now use the !changelog keyword to add a pre-upgrade message for the version currently in the manifest. All the text after the keyword will be used for the message.
The existing !bump command can be preemptively used to increase the package version.
