Would be great if you could provide an appimage build along side the deb and rpm builds.
Check out its benefits here
You can find more info about integrating it into your github builds here
(Originally posted by philipzae on GitHub.)
Hey! Thanks for reporting this—we’re planning to stick with Snapcraft for now because it allows us to deliver automatic updates across all Linux distros. (We’re actually planning on hiding the deb / rpm builds as soon as the snapcraft version is fully tested.) The autoupdate thing is huge for us—Linux users are typically 1-4 versions behind because we haven’t been able to update the app automatically on smaller linux distros eg ArchLinux (based on our automatic crash reports), and it causes quite a bit of additional support load.
I’ll leave this open but we’d really need a strong reason to invest time in another package format achieving most of the same goals as snapcraft but without first-class automatic updates.
(Originally posted by bengotow on GitHub.)
@bengotow self-updating software can be nice, and there’s tools that can do the same for AppImages.
In case you are using electron-builder (to generate the .deb package that is consumed by the snap build), please beware that it can produce proper AppImages without any real additional effort (just need to call it the right way).
Furthermore, they’ve built their own auto updater thing for Electron AppImages, see electron-userland/electron-builder#1138 for details.
Although, as the main author of AppImageUpdate (which will receive a self-updating feature as soon as possible, too) I am not entirely happy about Electron’s decision to build their own system (I’d have preferred to see them using libappimageupdate), however, to my knowledge it works fine, and suffices your auto update constraint.
Another very useful AppImage use case might be continuous deployment. Many projects, involving all AppImage tools, but also other big projects like Subsurface use it to ship binaries for the latest changes to the users, and with AppImageUpdate, people can easily update their software.
So, if distributing releases is not a use case, maybe those nightly builds are one you might even find useful for alpha/beta testing.
(Originally posted by TheAssassin on GitHub.)
Building and maintaining an AppImages is fairly trivial, if I file a PR for build automation of app images would your team consider merging?
Also You probably know by now, but Snap actually only works on Ubuntu distro it is not universal.
Let me know I’ll gladly put something together.
(Originally posted by oniGino on GitHub.)
@oniGino: While it’s still possible we’ll add AppImage support, testing packages can still be a bit non-trivial. Automation may address some of this, but perhaps not with bug diagnosis concerns. This is worth further discussion.
We’re actually looking at Flatpak to address the portability concerns, possibly instead of Snapcraft.
@TheAssassin: Fancy meeting you here! What’s your take on this now, given the current ecosystem of Appimage and Electron?