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? -- Mounir _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
