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. The AppImageUpdate tool will also be bundled to our appimage and integrated into Krita.
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)
Current state
----------------
WIP merge request: https://invent.kde.org/kde/krita/merge_requests/123
What to do next
--------------------
[ ] Consult with sysadmin.
[ ] Look into the UI of AppImageUpdate (it looks quite confusing, if the appimage is not signed)
[ ] Test with AppImageLauncher installed
Technical Questions:
[ ] Will this work with the mirror network? (it should: https://github.com/AppImage/AppImageUpdate/issues/57)
Code:
[ ] Error handling, logging
[X] Async QProcess in KisAppimageUpdater
[X] i18n for version messages
[X] Test KisManualUpdater with mocked up feed
[ ] User manual for updates
[ ] Disable updaters for Windows Store and Steam versions
Building:
[X] script for signing already built appimages
[ ] Different icons and app names for channels (useful for AppImageLauncher/appimaged users)
[ ] Real zsync URLs in build-image.sh
[ ] Use new version of linuxdeployqt (with our patch) (the binary factory image uses continuous build, does the image need to be rebuilt, or is it rebuilt every time it runs the job?; https://invent.kde.org/sysadmin/ci-tooling/blob/master/system-images/appimage-1604/setup-utilities)
[ ] documentation of the build process
Deploy plan (draft)
-----------------------
# Update the build environment in the binary factory
# New version of linuxdeployqt (the necessary change is in master now)
# Add AppImageUpdate to dependencies (or is it OK to download it new from github every time?)
# Merge the code to master (https://invent.kde.org/kde/krita/merge_requests/123)
# Let two successive nightlies build
# Test updating nightlies (directly from the binary factory)
# Testing the mirror network; Beta testing
# Prepare beta builds (we will need two betas for this)
# Test updating the betas
# Prepare questions for the beta survey
# Release the betas, gather feedback