On Jun 18, 2013 5:51 PM, "Marcos Caceres" <[email protected]> wrote: > > > > On Tuesday, 18 June 2013 at 13:41, Mounir Lamouri wrote: > > > On 17/06/13 19:49, Marcos Caceres wrote: > > > > > > > > > > > > On Monday, June 17, 2013 at 6:01 PM, Matt Basta wrote: > > > > > > > I don't think this is viable solution since it's not backwards compatible. Older devices won't be able to understand the manifest. > > > > > > So, we are probably going to keep hitting this problem going forward, as we are not standardizing just Mozilla's manifest format (we are trying to learn from all available formats to create a solution that is right for the Web). Other W3C members have their own requirements, etc. and they've been quite welcoming of Mozilla's manifest as initial input - but the reality is that stuff is probably going to have to change in ways that may break compatibility with our format. > > > > > > Question is, what's the best way to handle breaking changes? > > > > Jonas and I have been talking about this a couple of times. This is > > something that also applies to APIs. If we change an API to something > > drastically different we might want to be able to do that without > > breaking too many applications. A solution to do this would be to > > introduce a property in the manifest file like "manifest_version" or > > "api_version" or "platform_version" (whatever...). > > > > The manifest parsing would depend on the version number and the > > available APIs might too. Some manifest properties and APIs would only > > be available to newer versions and we could deprecate older versions and > > then even stop supporting them. > > > > The problem of that solution is that it sounds pretty specific to > > implementations trying to experiment things. We could definitively make > > this Mozilla only with something like "platform_version": "tef", > > "platform_version": "leo", ... Then, the W3C specification might or > > might not specify a system where there is such property (which would > > have different set of values). > > > > How does that sound? > I think it sounds ok for the Moz side (as we can control how long we support a format version for, etc.) - but adding a manifest versioning scheme for the Web platform (W3C-side) won't fly because it would be difficult to maintain across user agents.
My thinking was to use some sort of versioned manifest for now, as long as we only use it in prefixed mozApps.install. Once we switch to an unprefixed function, we also need to use a standardized manifest and forever maintain compatibility with that manifest format. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
