Sprints

User Stories

1. "I as a user want to download an AppImage from the OCS Desktop app, the openDesktop.org stores an/or the original author's download page, and run it through AppImageUpdate in order to update to the latest version"
2. "I as a user want to update an AppImage using the OCS Desktop app, regardless of where I had downloaded it from originally, and even if I copied it over network, USB, etc., in order not to have to manually manage repositories, etc."
3. "I as an application author want to make my AppImage self-updateable from the menu, "Check for newer version and update..."
4. "I as an application author who puts OCS-provided AppImages into openDesktop.org stores don't want to need to do anything special to have automatic updates work"
5. "I as a zsync user want to be able to use the new infrastructure with existing zsync files and the old zsync with the new zync files to maximize compatibility"

Sprint 1: AppImageUpdate (02.10.-20.10.2017)

Architecture and estimation

• mock libappimageupdate: To find out how to consume this from OCS-Store
  ✅
• libzsync2: Convert the functionality of zsync-curl into libzsync (using libcurl), keeping librcksum and libzsync code, but rewriting frontend code), including new zsync2 CLI tool (demo app, drop-in replacement for zsync/zsync-curl) and Unit tests -- 7 days
  ✅
• libappimageupdate: Convert the functionality of the appimageupdate bash script into a C/C++ library, and test it with unit/functionality tests -- 2 days
  ✅
• appimageupdate: Write a CLI frontend for libappimageupdate providing the same functionality as the current tool - 1 days
  ✅
• (Qt based? - ideally small at runtime. Statically comiled Qt? FLTK if it looks native? Vala/GTK+ 2?) AppImageUpdate: Write a GUI tool using libappimageupdate that can serve as a drop-in replacement for the old AppImageUpdate GUI tool -- 1 days
  ✅

If time left:

• Spend 2 hours trying to understand how bittorrent works and how much it really differs from the above, and whether the two could be merged (timeboxed to 2 hours)
• Think about how AppImageUpdate could be embedded into AppImages, and how it could be detected by companion tools (such as the standalone AppImageUpdate or OCS-Store)
  ✅

Total: about 12 working days

Sprint 2: AppImageUpdate (23.10.-10.11.2017)

• libappimageupdate: Finish the library and document its use for Akira to integrate into OCS-Store desktop app: 5 days
  ✅
• appimageupdate: Fix the remaining issues so that a) AppImageUpdate can update itself b) errors are properly handled with clear error messages 2 days
  ✅
• Make it easy to embed AppImageUpdate could be embedded into AppImages for a self-updating experience similar to Sparkle Framework for macOS: 1 day
• Work with Akira to integrate into OCS-Store desktop app 2-3 days
• Improve standalone tools' UX and feature completeness (zsync2 CLI and AppImageUpdate CLI/GUI) 2 days
  ✅

Total: 10 working days

Sprint 3: zsync2, zsyncmake2 (11.11.-29.11.2017)

• Implement remaining feature requests (consult GitHub issues of AppImageUpdate/zsync2) (5d) ✅
• Work with Akira on integrating AppImage update feature into OCS-Desktop app similar to the screenshots provided (2d)
• Implement zsyncmake2 (2-3d) ✅
  • Last big feature missing for zsync2
  • Introducing "custom headers" (should (but don't have to) be prefixed with X-) which can be used to store auxiliary information, e.g. by sites like openDesktop.org, or AppImageUpdate for more efficient updates
  • Ability to create a proper C++ API for use by third party applications (AppImageKit itself will probably make use of this)
• Finish self update concept ✅
  • Incorporate feedback from potential users
  • Document in the AppImage wiki (0.5d - 1d)
  • Add self updating to existing libappimageupdate guide (0.5d)
• Remaining time:
  • Improve CMake configuration (fix issues, improve inter-operability) ✅
  • Move AppImageUpdate information to AppImage Wiki (reason: easier to find information on all things AppImage if it is not scattered around)

Sprint 4: AppImageKit (30.11.-16.12.2017) (draft; not exhaustive)

• Rework build system ✅
  • Finally make full switch to CMake
  • Fix dependency issues ✅
  • Integrate libappimage into the rest of the build system
  • Restructure repository layout
• Continue to work with Akira on integrating AppImage update feature into OCS-Desktop app similar to the screenshots provided ✅
• Work with Alexis on writing and improving a libappimage for use within AppImageKit and third party projects
  • Expose common functionality like desktop integration
  • Improve code quality, improve portability (e.g., by removing the dependency on glib)
  • Potential users: Linux distributions, potentially also other users like OCS-Desktop or OCS websites
• (azubieta) appimaged overhaul ✅
  • Fix memory leaks
  • Make more efficient
  • Determine whether rewrite is needed
• XDG thumbnailer spec conforming AppImage type-2 thumbnailer (note: should have no dependencies in addition to those in AppImage.c if possible so that we can re-use the code there) ✅ (remark: XDG thumbnailing doesn't work on KDE based desktops, due to lack of support for the standard, working on a custom thumbnailer)

18.12.17 - 26.01.2018 -- no sprint planned

• Try to merge current pull requests in AppImageKit
• Review existing code
• Housekeeping
  • Prioritize existing issues
  • Close outdated and/or resolved issues
• Meditate about existing feature requests, and make plans about implementation
• Finish OCS-Store AppImage updating implementation
  • Think about desktop integration
  • Make use of code contributed by @azubieta regarding libappimage and desktop integration

Sprint 5: AppImage support in third party tools (05.02. - 16.02.)

• Test AppImage update feature integrated by Akira into OCS-Desktop app and give feedback
• Consider writing plugin for GNOME Software to display AppImage data from OCS (and/or https://appimage.github.io/feed.json) - see https://github.com/AppImage/AppImageKit/issues/244 and https://github.com/AppImage/AppImageKit/issues/58#issuecomment-275901950
• "Plasma Discover will have Flatpak and Snap in 5.12" - bring in AppImage using data from OCS (and/or https://appimage.github.io/feed.json)
• Implement reproducible builds -- https://github.com/AppImage/AppImageKit/issues/625
• Evaluate AppImageUpdate UI implementation in Qt/Gtk+
  • should be designed to be reusable, so that other applications can just link to libappimageupdate and the related UI class and display a standard UI which automatically updates the according AppImage

Concepts

GUI integration

Applications making use of libappimageupdate should implement one of two cases

Case 1: An application that "updates itself" (example: Krita). Role model is Sparkle Framework on the Mac. Implement a "Check for updates..." menu item that, when selected by the user, checks for updates and has a GUI similar to this:

Case 1: An application that "updates other AppImages" (example: OCS-Store app). Role model is Mac App Store on the Mac. Make the application find AppImages that exist on the user's system in certain directories (listed here), and offer a GUI similar to this:

Only in the case of errors, give additional information to the user and tell what happened in an error dialog box:

As a bonus, place an icon into the dock and a progress bar into the icon like this:

There is APIs for that on the Linux desktop: See https://github.com/AppImage/AppImageKit/issues/256