Skip to content

Sprints

Jump to bottom
TheAssassin edited this page Feb 13, 2018 · 30 revisions

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)

icons

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.)

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:

sparkle1 sparkle2 sparkle3

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:

mas1 mas2

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

error

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

dld

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

Clone this wiki locally