Future of AppImageKit

1. Create new repository https://github.com/AppImage/appimagetool
   • Copy appimagetool code from AppImageKit (w/o runtime, AppRun)
   • Implement static building of main binary on Alpine Linux for releases
   • Build mksquashfs statically as part of the build pipeline
   • Build desktop-file-utils statically as part of the build pipeline
   • Release AppImages for architectures amd64, i386, armhf, aarch64
   • Maintain old CLI (i.e., no fancy changes for now!)
2. Set up https://api.appimage.org/releases
3. Review type2-runtime repository and bring it into a state which allows for development and releases by distributions, too
4. Make new appimagetool download suitable type-2 runtime automatically from GitHub releases during runtime (unless user specifies custom binary)
5. Move AppRun.c to pkg2appimage and add a big fat warning "Please do not use this outside of pkg2appimage" to the source code (deadline: December 2023)
6. Talk to OBS folks about how they can build appimagetool from its new home (and, more importantly, build different runtimes and make them available to appimagetool)
7. Create migration guide for users to help them adopt the new URLs and workflows
8. Rename current master in AppImageKit to old and add a new main branch that informs users about the changes
9. To be discussed: Consider moving AppImage specification from its own dedicated repository into AppImageKit
10. Move appimagetool to C++ and drop all GLib/GIO related dependencies (keeping CLI compatible, may get higher priority over time)
11. Develop new commandline user interface for appimagetool (we might want to rediscuss which language to use then)