AppImageCommunity
Assemble "Release notes" by looking at the GitHub API
Sparkle Framework on macOS shows these information windows:
But they have an extra feed (AppCast) for this kind of metadata, which is extra work to produce.
QGitHubReleaseAPI seems to be able to put together something similar from the information on GitHub:
https://github.com/velnias75/QGitHubReleaseAPI
The library is not well maintained and lacks licensing information. Also, it doesn't "put together" anything, it is merely a library downloading the JSON blob from GitHub's releases API, and display the description with a Markdown renderer.
GitHub Releases release notes often don't contain anything interesting in my experiences, it's mostly bigger projects who put together some words as release notes. Especially for continuous releases, there's no real value of showing a link to the Travis build log for instance.
So, yes, could be shown. Definitely not a priority right now.
It's meant as inspiration - can also reimplement it. But agree, not the highest priority right now. Only once people start to ask for "changelogs" and we need to pull them out of thin air.
Sure. But I guess we'll have to write that ourselves then. Shouldn't be too hard, I'll just have to look into JSON libraries for C++.
Now that we have a somewhat functional Qt UI built as reusable widget, we could add another widget that can be shown after the update check which shows such a "release notes" window.
But first, we need to amend the AppImage specification and specify methods for the supported update information types defining where and how to download these release notes.
Now that we have a somewhat functional Qt UI built as reusable widget, we could add another widget that can be shown after the update check which shows such a "release notes" window.
Cool :+1:
But first, we need to amend the AppImage specification and specify methods for the supported update information types defining where and how to download these release notes.
Do we? I don't think the AppImage spec has to be involved. This is merely a feature of the client, not of the AppImage format or the format of the update information.
Do we? I don't think the AppImage spec has to be involved. This is merely a feature of the client, not of the AppImage format or the format of the update information.
Thats true. For GitHub , I can simply take the json value for the key 'body' to get the release notes. It will be empty in case if there is no changelog given by the author. But I can't say the same for a Web Server and Bintray. One workaround is to include the link to the raw changelog file ( In case of a Web Server or Bintary).
This is what I did for my version of API for changlog support.
Changelog = jsonObject["body"].toString();
and A function to mention a direct link to the changelog file (MarkDown). In case the direct changelog file is empty , Github release notes will be used. Simple right ?... ( If both are empty then there is no release note. )
Of course it is something update information dependent. With the GitHub releases type, for example, we could support it because we download the release information anyway, and could provide it to the user as a property, for example. But some AppImages (like appimaged or appimagetool -- note for myself: update those strings) still use the plain zsync type. Now, while those are on GitHub, too, they won't support this feature. I think this needs to be documented. And since the AppImage specification is responsible for update stuff, I'd put it there.
But I can't say the same for a Web Server and Bintray.
This is specifically about the GitHub API. On Bintray for example, there's no "changelogs" like the GitHub release page has them. There's no problem if we didn't support release notes for anything but GitHub. But we should at least document it. That's my point.
we should at least document it
Sure - but I am not convinced that the AppImage specification is the place to document where AppImageUpdate parses changelogs. I'd assume the AppImageUpdate documentation is the best place for that?
Thinking about it, I think you're right. We can put it in this repo's docs. The spec doesn't care about what features are implemented upon the information read from the AppImage.