Will AppImage be the preferred installation method, or will both be maintained at identical revision versions?
Brief answer: Both AppImage and Deb packages will be maintained at identical revision versions, for both testing and final releases, until I can properly support arm64 Raspberry Pi’s with AppImage, Flatpak and Snap packages.
The background to that answer:
Universal installers, such as AppImage, Snap, and Flatpak offer one advantage over traditional packaging formats like DEB, RPM, and AUR packages, which is that the developer has more control over which versions of libraries that the program depends on are used to run the program. This allows one to test the program for the certainty that it’ll run the same way for anyone who uses it, and for this reason AppImage, Snap, and Flatpak are equally preferred installation methods for final releases of QPrompt.
Now, each of those versions are built using a different pipeline. KDE Craft, the pipeline I’m using to build the AppImage, turns out to be the same pipeline used to create Windows and macOS installs, which helps reduce variables when testing because I can sync all dependencies to the same versions across all operating systems. This is why I provide betas as AppImages but not as Snaps or Flatpaks.
The Debian package is an exception to all of this… I only make it because 2 out of 3 build pipelines didn’t support arm64 architecture at the time QPrompt was first released, and because the one that did, Flatpak, was having trouble with graphics acceleration on the Raspberry Pi.
I’ll continue to create deb installers for the Raspberry Pi until there’s a way to create arm64 AppImages without having to build another pipeline just for that. Snap now provides arm64 support, but I’ll continue to create the Deb until AppImage works as well, because Raspberry Pi OS comes with no built in support for Snap or Flatpak. Requiring users to install something else in order to use QPrompt would add friction, which I like to keep to a minimum.