Marcos, All good points, and definitely things we need to consider.
I agree that versioning the manifest comes with a responsibility to manage that process and make sure new versions are being released thoughtfully and on reasonably long cycles, but I think it's a good tool to have to allow us to surmount issues relating to existing fields that we didn't consider at the time (I'd be interested in hearing other suggestions beyond versioning that addresses this without having to rename fields all the time). And I agree, given that the current manifest isn't versioned makes things tricky. If we are using versioning, and the manifest is marked v2 but has v3 properties in it, I would assume that it would be parsed as a v2 manifest and those v3/v4 fields would be ignored. The developer would need to correct his or her mistake in this case. And in Google's case the phase out of v1 support is happening over the course of 6 months, first blocking submission and then eventual delisting apps. We'd have to figure out something similar to reduce the maintenance burden. Having multiple marketplaces is certainly a wrinkle. But as the platform/apis change we'll have to have some way of communicating to marketplaces that certain things/versions become deprecated over time. Best, -Travis ----- Original Message ----- From: "Marcos Caceres" <mcace...@mozilla.com> To: "Travis Choma" <tch...@mozilla.com> Cc: "Mounir Lamouri" <mou...@lamouri.fr>, "Vivien Nicolas" <vnico...@mozilla.com>, "dev-webapps" <dev-webapps@lists.mozilla.org>, "Matt Basta" <mba...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc>, "Tim Guan-tin Chien" <timdr...@mozilla.com> Sent: Tuesday, June 18, 2013 9:11:27 AM Subject: Re: Migrating to W3C format, was Re: Icon sizes and display densities On Tuesday, 18 June 2013 at 16:33, Travis Choma wrote: > Mounir, this sounds reasonable to me. Google also had to version their > manifest file to deal with changes they introduced in v2 but still wanted v1 > manifests to work properly and retain their original syntax and semantics. > This could solve problems going forward, but current generation of devices would still be affected as they would just ignore "manifest_version" (i.e., they remain version agnostic - hence icon remains a problem). As I understand it "manifest_version" literally means "process this manifest with this particular code path". We have to be careful that this doesn't get crazy, because if we start changing stuff and we want to support legacy content, then we need to make sure everything for each manifest_version continues to work without regressions. It also ties the manifest to a versioning system, which means we would need rules about what constitutes a version change and what happens if version 3 or 4 stuff appears in the manifest marked as 2 (ignore it? use it?). Google can get away with using this scheme because their apps can only be installed form their store (and not the open Web) - hence, they can remove apps with outdated manifests from their store when they feel like it. In our case, we have to be more mindful because users are not restricted from where they install hosted apps from (and we have no way of forcing developers to update outdated manifests on the open Web). Just some thoughts… -- Marcos Caceres _______________________________________________ dev-webapps mailing list dev-webapps@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-webapps
