How does it work
----------------------
Updateable appimage needs to have update information embedded. This update information is basically an HTTP URL of a file containing metadata needed for the update to happen - zsync. While the appimage filename may change between version, the zsync file needs to have stable URL.
In our appimage build script (build-image.sh), we pass the zsync URL to linuxdeployqt, which is the binary building the appimage. (Note: I have extended linuxdeployqt to enable that, it is now merged in master.)
Results from the build are an appimage and also the zsync file. We upload those two files to an HTTP server.
With all of this in place, I can run 'AppImageUpdate old-krita-version.appimage' on my computer. (AppImageUpdate is a tool available from github as an appimage :) This tool connects to the zsync URL, does it's magic and I now have both the old and new versions on my computer.
If we want to have Krita updating itself, we can bundle AppImageUpdate and run it directly from the application (demo here: https://github.com/AppImage/QtAppImageUpdateExample).
Current state
----------------
I have a local proof of concept with AppImageUpdate, I have not touched Krita's code, as that needs discussion first. (I build the appimages on Dmitry's docker image, then use locally installed nginx to serve the files).
PoC video: {F7290832}
WIP merge request:
What to do next
--------------------
* Decide on the workflow and UX.
* Consult with sysadmin.
* Look into the UI of AppImageUpdate (it looks quite confusing, if the appimage is not signed)
What I suggest is to have separate release channels, which can be used side by side. So the user can have Krita Stable, which updates to the latest stable version, and then Krita Beta on the side, which they use for testing. Adventurous users/developers/testers can have Krita Next channel, etc. I believe it is useful to have all of these channels updateable:
* More incentive for stable users to update
* Easier/more streamlined participation in testing
* Having the same mechanism on Next would help us with enhancements and regressions of the appimage build process (though the process wouldn't be exactly the same as for stable)
Question: do we want to integrate updates into krita? Or do we want to leave it to the user, who would then use AppImageUpdate or AppImageLauncher to update?
Should we wish to integrate it into Krita: the update itself would not happen automatically upon detecting new version. We would prompt the user to initiate the update manually.
Question: Where and how? We already have new version notifications and a toggle for update checks on the welcome screen, we might just add a button there. (What if the user has Krita set to restore session and does not see the welcome screen?)
Technical Questions:
* Will this work with the mirror network?
* Can we serve Next from CI directly? (Users already download it from there, but is it technically possible? Does it support Ranges?)