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 stateWhat 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
----------------
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).* 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
----------------
PoC video: {F7290832}
WIP merge request: https://invent.kde.org/kde/krita/merge_requests/123
What to do next
--------------------
* Decide on the workflow and UX[ ] Consult with sysadmin.
* Consult with sysadmin.[ ] Look into the UI of AppImageUpdate (it looks quite confusing, if the appimage is not signed)
Technical Questions:
* Look into the UI of AppImageUpdate (it looks quite confusing, if[ ] Will this work with the appimage is not signed)mirror network?
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 updateablCode:
* More incentive for stable users to update[ ] How to use RAII m_versionUpdater in KisWelcomePageWidget?
* Easier/more streamlined participation in testing[ ] Error handling, logging
* 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?[ ] Async QProcess in KisAppimageUpdater
[ ] i18n for version messages
[ ] Test KisManualUpdater with mocked up feed
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 QuestionsBuilding:
* Will this work with the mirror network?[ ] Different icons and app names for channels (useful for AppImageLauncher/appimaged users)
* Can we serve Next from CI directly? (Users already download it from there, but is it technically possible? Does it support Ranges?)
[ ] Real zsync URLs in build-image.sh