HTML5 App Releases

This is a preliminary draft, to ask questions in order to start ironing out the details of a good release regime for the HTML5 app.

We have good support available for our HTML5 app releases. We have to organize our releases well in order to enjoy the benefits of those services and release in a timely manner.

In addition, the combination of corporate backing with an open source development project offers some unusual opportunities.

Ideally, we will have release practices that are rigorous enough to get the benefits of our support services without constraining our efforts any more than necessary.

Table of Contents What sorts of coordination? Support Coordination Testing and Release Testing Support Questions Customer Support Customer Support Questions

What sorts of coordination?

The various constituencies need to be informed about aspects and timing of the development and release:

• Developers need to settle outstanding work that will be included in the release, reconciling their efforts with those of others.
• Testers need to account for new and changed features in their test regimes, for adequate exercise of the app before release.
• Customer support needs to be prepared for new questions, after release.
• People handling public relations need to be informed about improvements and pitfalls to convey.
• Vested users need to be informed about availability and consequences of upgrading.

With our small (core) development team, we developers are involved, to some degree, in many of the various roles. We write release notes, do preliminary manual tests, maintain continuous integration testing, and we can conduct some targeted end-user testing to, for instance, exercise bug fixes. But generally, we need to deliberately inform and engage with supporting personnel, so they can do their thing, to together produce healthy, timely releases.

Support Coordination

Testing and Release

• We have to describe the behavior of the app clearly, for QA testing support. (See our ongoing Functional Operations document.)
• We have to coordinate schedules with internal testers for trials before releases.
• We maintain a Travis Continuous Integration build, thanks to their free (to open source project) facilities.
• Similarly, we can provide advance access to new releases to the user community, using facilities like share rooms, eg our mobile client Android releases share room, and official test distribution conduits, like the Android Play store alpha and beta channels or iOS test distribution facilities like TestFlight, app.io, mobtest.
  • We have started to try using Android Play store beta channel for conveying beta releases of bug fixes for trials by users reporting the problems. I'm wondering whether it would also be useful to use the Android Play store alpha channel for open, new-feature trial releases?

Testing Support Questions

• One pressing question is how to best coordinate schedules with our testing support to get timely test coverage? Is there a way to arrange it for quick turnaround?
• What more do we need to provide, beyond the Functional Operations document and the release notes, to keep them filled in on testing concerns?

Customer Support

In order to get the benefits of front-line customer support, we need to keep our internal supports informed about several things:

• Impending (near-term) release schedules, as they become clear
• Impending release characteristics, including new features, bug fixes, platform criteria, etc.
• Some sense of medium-term efforts - what we're currently concentrating on for our next major efforts
• Some sense of disposition of ongoing problems - our current plans for outstanding unsolved problems
• Some of our efforts are for internal projects. We might want to provide separate reporting and status tracking for them.

Customer Support Questions

• How do we keep customer support filled in on development and release landmarks, so that new developments do not catch them by surprise?
• We need to find a good balance in proactively informing them, so they can field some basic questions for us rather, than having to pass them on to us
• We need to identify good ways to organize the information so that it is easily available when and where it is necessary.
  • Could we use our repository issue tracking infrastructure to convey the info, or at least organize it on our side for easy harvesting and conveying in some other ways?
    • What is done by other SpiderOak projects?
  • Could we use special item designations in our issue tracker for project status tracking?
  • Can we adapt use of huboard to make it easy for CR and testing folk to track what's going on?
  • Or use a separate repository dedicated to that purpose?