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
- Find a good way to disable the updaters on Linux/Steam, Windows/Steam and Windows/Store
- Test on mirror network (it should work: https://github.com/AppImage/AppImageUpdate/issues/57)
- Add real zsync URLs in AppImage build scripts
- Documentation of the build process
- User manual for updates
- Add AppImageUpdate to https://files.kde.org/krita/build/ (source: https://github.com/AppImage/AppImageUpdate/releases/download/continuous/AppImageUpdate-x86_64.AppImage)
- test with https and with redirects
- get nightly usage from statistics
Target deployment state
- The build pipelines on the Binary Factory
- sign all AppImages with GPG
- publish generated zsync metadata files along with the AppImage
- Next and Plus updates are served from the Binary Factory (through the https://binary-factory.kde.org/job/<job>/lastSuccessfulBuild/artifact/ URL)
- Beta and Stable updates are served from the mirror network
Deploy plan
- Merge the code to master (https://invent.kde.org/kde/krita/merge_requests/123), with updaters disabled (cmake flag)
- Update the build environment in the binary factory
- New version of linuxdeployqt (the necessary change is in master now)
- GPG key for signing
- add the signing script to our pipelines
- Enable updaters in master
- Let two successive nightlies build
- Test updating nightlies (directly from the binary factory)
- When the code is included in an upcoming release, update Plus and Release AppImage pipelines in 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