Make appimages updateable
Open, Needs TriagePublic

Description

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
  • Add final branding icons
  • 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

Deploy plan (draft)

  1. Update the build environment in the binary factory
    1. New version of linuxdeployqt (the necessary change is in master now)
    2. Add AppImageUpdate to dependencies (or is it OK to download it new from github every time?)
  2. Merge the code to master (https://invent.kde.org/kde/krita/merge_requests/123)
  3. Let two successive nightlies build
  4. Test updating nightlies (directly from the binary factory)
  5. Testing the mirror network; Beta testing
    1. Prepare beta builds (we will need two betas for this)
    2. Test updating the betas
    3. Prepare questions for the beta survey
    4. Release the betas, gather feedback

Notes

amedonosova updated the task description. (Show Details)Aug 29 2019, 6:34 AM
rempt added a subscriber: rempt.Aug 29 2019, 7:32 AM
  • I would like integration into Krita itself
  • The video was really useful since it shows that after updating, the user has two appimages -- I was a bit worried that the user would lose access to the older version
  • We probably should also make the updated appimage executable
amedonosova updated the task description. (Show Details)Sep 7 2019, 12:24 PM
amedonosova updated the task description. (Show Details)Sep 11 2019, 5:28 AM
amedonosova updated the task description. (Show Details)Sep 11 2019, 5:32 AM
amedonosova updated the task description. (Show Details)Sep 13 2019, 4:16 AM

Current progress (still on localhost; the size of the appimage is not final, it's just my debug build). The core of the check and update process is done. I am not sure what to do with the UI part and reporting errors to users. I have added the update button and placeholder messages to the original area in the Start section, but it feels crowded and overall weird to me. Errors are logged to the usage log but not propagated to the user interface right now (apart from 'Error occurred' message). @scottpetrovic, may I ask you for a bit of your time to look at it with me?

On the side I am working on a deploy plan: it won't be extremely complicated, but we will need changes in the build environment and some tests on production infrastructure. I will add that to this task when it is ready.

maybe instead of 'update now', it could just say "update to newer version".

What does the link do after it is done updating. The "To complete the update, run the new version". Does that restart Krita?

What does the link do after it is done updating. The "To complete the update, run the new version". Does that restart Krita?

All those messages are just text. Only thing that does something is the update button.

As for the restart: the updater downloads the new version and stores it alongside the old one. If the new image passes validation in the updater (which features gpg signatures, I am not this far yet), it displays a button to launch the appimage of the new version. If you click that button, the updater makes the new appimage executable and runs it. We can catch the return value of the updater and close Krita upon success. Question is whether that would work if the user has set Krita to only allow one instance of itself in the settings.

Also, if I read the AppImageUpdate code correctly, we get 0 as return value both in the case the new version was started and in the case the user clicks 'Close', without restart taking place. I have to look deeper into it.

amedonosova updated the task description. (Show Details)Sep 15 2019, 4:20 AM
amedonosova updated the task description. (Show Details)Sep 17 2019, 8:41 AM
amedonosova updated the task description. (Show Details)Sep 18 2019, 7:54 AM

I’m trying out a prototype in which I have decoupled the development build alert and new version notifications:

  • When appimage updater is in use, there are also updates for dev builds. The area next to Start header is too crowded then.
  • It makes more sense to me if the updater notification is under the “Check for updates” checkbox, not on the other side of the window.

The frame only appears if there is a successfully detected update, an error occurs during updating, or it shows the message about need of restarting. If the check for updates fails, the error is logged to the usage log (for user support), but no message is displayed to the user. That is deliberate, to avoid overloading our user support with local network issues and other problems out of our control (which are the most likely cases of failure in this case).

Does it make sense? Can it be done better?

(The "download" link still points to the release notes from the RSS.)

To the problem of relaunching the updated appimage by AppImageUpdate we discussed previously: there is an issue open concerning that, https://github.com/AppImage/AppImageUpdate/issues/44, with no solution for now.

Apart from the welcome page, we might add an Update action to the main menu (Tools? Or Help?). Some users may skip the welcome page entirely (e.g. by setting Krita to restore session on load). By having the update button only on the welcome page, they need to close all their documents to reach the update functionality.

amedonosova updated the task description. (Show Details)Sep 23 2019, 6:40 AM
amedonosova updated the task description. (Show Details)Sep 23 2019, 7:07 AM
amedonosova updated the task description. (Show Details)Sep 26 2019, 8:27 AM
amedonosova updated the task description. (Show Details)Oct 7 2019, 8:56 AM
amedonosova updated the task description. (Show Details)Oct 15 2019, 8:25 AM
amedonosova updated the task description. (Show Details)Oct 26 2019, 8:45 AM
amedonosova updated the task description. (Show Details)Nov 8 2019, 9:41 AM