Versioning and compatibility

[alexanderedge]

We had a brief conversation about versioning and compatibility between the native clients and the webview, so I thought we should get something in writing about how we're going to handle changes to the WebView / Native Thrift API over time.

[alexanderedge]

We've got nativeThriftPackageVersion on the native side and webviewThriftPackage on the webview side. How are these version numbers set currently?

Here are possible scenarios:

Rendered page version	Native version	Outcome
1	1	✅
1	2	⚠️ native layer may not be able to call functions on the page
2	1	⚠️ page may not be able to call functions on the native layer

Over time, is it possible to avoid a hot mess of if version >= 𝑥 throughout the native and JS code?

[alexanderedge]

cc @maxspencer @ChrisOwen101

[alexanderedge]

We've got nativeThriftPackageVersion on the native side and webviewThriftPackage on the webview side. How are these version numbers set currently?

This might be a warning that we need thorough documentation with which functions are supported by which versions.

[alexanderedge]

This is also linked to #12, since if the native layer never calls functions on the web page, then one of the scenarios above is impossible.

[webb04]

Can't we assume that the rendered page version will always be >= nativeVersion?

[alexanderedge]

If a new build of the app accesses a rendered page that is cached by Fastly, then could this happen?

[webb04]

Hmm yeah, maybe we put a hash on renderedItem url so that when the JavaScript changes, that cache is invalid?

We do have version numbers available to each other but it won't be nice to have if statements everywhere. We should build it so that if the function doesn't exist, nothing happens.

I think the majority of cases will be the webview calling into the native layer?