3
edits
(Thoughts on change over time.) |
|||
| Line 4: | Line 4: | ||
For Windows manifest file locations, would it also follow similar to chrome in, first the 32-bit registry is queried, then the 64-bit registry? [[User:Kattamine|Kattamine]] ([[User talk:Kattamine|talk]]) 01:13, 29 April 2016 (PDT) | For Windows manifest file locations, would it also follow similar to chrome in, first the 32-bit registry is queried, then the 64-bit registry? [[User:Kattamine|Kattamine]] ([[User talk:Kattamine|talk]]) 01:13, 29 April 2016 (PDT) | ||
:Good question, I'd like to take this over to bug 1270359 though. [[User:aswan|aswan]] ([[User talk:aswan|talk]]) 22:13, 8 May 2016 (PDT) | :Good question, I'd like to take this over to bug 1270359 though. [[User:aswan|aswan]] ([[User talk:aswan|talk]]) 22:13, 8 May 2016 (PDT) | ||
== Host Manifests - version == | |||
For a chrome plugin using connectNative, just coming to a situation where we are trying to understand a best way to manage the 2 release cycles of such a plugin and the native component. | |||
It seems likely that the native application may be older more often than the plugin especially where they are automatically updated. | |||
Mainly an issue when the API is being changed and a consideration for backward compatibility. | |||
Would it make sense to add some sort of version to the native manifest, and a version range required in the plugin? [[User:Kattamine|Kattamine]] ([[User talk:Kattamine|talk]]) | |||
edits