Non-engineering implications of a packaged app
- What is our release schedule?
- ...for Gaia
- ...for the website (in case some iframed packaged apps persist)
- How/How hard should we push people to update their marketplace app?
- How do we push critical bugfixes?
The release schedule is a big deal, because currently we accommodate a lot of last-minute requests and under-planned features. The idea currently is that we can just patch it; "just patch it" with a package becomes a lot dicier unless we can more reliably get people to update.
So, if our production schedule is longer (or has code freeze dates, etc), the impacts could be:
- What happens with a third-party partner change?
- How do we handle feature requests during our production cycle? Is there a cutoff point?
- By when does L10n need to get something?
- By when does QA need to get something?
- How far in advance do features need to be defined? Designed? Communicated to FxOS?
- How do we structure integration testing (and planning) around this cycle?
You'll find many of these things also described here: Proposal of what it means to be a packaged app
Packaged app or not
Should we be a packaged app?
|First boot time||Slow||Fast||600kb of JS and CSS, images and index.html loaded from the network. As a packaged app its all local.|
|Second boot time||No change||A bit faster||No network requests against servers to see what hasn't changed.|
|Gaia schedule||Independent||Tied||Packages can be released any time, but packages in Gaia must be tied to the releases|
|Updates||Easy (currently weekly)||Very slow and require user action||Slowness depends upon Gaia schedules. Updates for iframe can also be non-easy (iframe != no package updates, it depends on the change).|
|Process||Little||More||If release takes 6 months, lots of time ahead planning|
|QA cycles||More||Less||Debateable, there will probably be more to QA|
|Hacky code||More||Less||Testing is possible, but we are using postMessage to work around the packaging|
|Preload data||None||Possible||(db) - not a huge use case|
|The Web||Yes||It's not the web|
|Release Cycle||short, weekly||long, ~1 year||It takes 3-6 months for product, 6 months dev, + 1 - 2 for Gaia testing + 1 - 3 OEM acceptance and shipping to consumers|
|Localizations||more planning||less planning||FxOS devices may have 1 - 6 months advance notice|
|installs_allowed_from||Works fine||Needs an iframe||Oh the irony|
Packaged apps on phones
- iframed: a page that loads the rest of the marketplace in an iframe (https://github.com/mozilla/fireplace/blob/master/yulelog/index.html)
- packaged: a more fully packaged version of the marketplace, that has all of Fireplace in it s
|1.1||iframed||https://marketplace.firefox.com/packaged.webapp||app://marketplace.firefox.com||Upgrade path maybe an issue for the ZTE Open issues 962524|
|Tarako 1.3 downloaded from the Marketplace||packaged||https://marketplace.firefox.com/marketplace-package.webapp||app://packaged.marketplace.firefox.com||When downloaded from the Marketplace|
|Tarako 1.3 according to Gaia||packaged||https://marketplace.firefox.com/marketplace-package.webapp||app://marketplace.firefox.com||According to Gaia (https://github.com/mozilla-b2g/gaia/blob/v1.3t/external-apps/marketplace.firefox.com/metadata.json)|
Bugs of interest: https://bugzilla.mozilla.org/show_bug.cgi?id=929602
- 1.1 source: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/09/2013-09-06-04-32-05-mozilla-b2g18_v1_0_1/b2g-18.0.multi.linux-i686-localizer.tar.bz2
- 1.2 source: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2013/12/2013-12-31-00-40-01-mozilla-b2g26_v1_2/b2g-26.0.multi.linux-i686.tar.bz2
- 1.3 source: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2014-08-29-02-40-02-mozilla-b2g28_v1_3/b2g-28.0.multi.linux-i686.tar.bz2
- 1.4 source: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2014-08-26-00-02-02-mozilla-b2g30_v1_4/b2g-30.0.multi.linux-i686.tar.bz2
- 2.0 source: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2014-08-26-00-02-04-mozilla-b2g32_v2_0/b2g-32.0.multi.linux-i686.tar.bz2