Frontend code versioning for RPC

[ZakarFin]

This is a roadmap item. Responsible party is NLS Finland.

Initial support for more graceful version negotiation. Mainly for clients connecting with RPC. Currently any RPC-clients will receive the latest Oskari code immediately when a new version is updated to the Oskari instance hosting the embedded map. As there might be backwards-incompatible changes the software built on RPC might break at the same time.

We should add support for a version parameter for the embedded map url (iframe src) that could be used to request a specific version of the frontend code of Oskari. Naturally it's the responsibility of the administrator of each Oskari instance which versions are supported and for how long, but Oskari should enable this kind of functionality. This way an older version of the client code could be used by the RPC-clients to make the migration process more flexible when versions are updated.

[ZakarFin]

oskariorg/oskari-server#897 enables instance admins to enable embedded maps to specify URL-parameter v=[version] for requesting a non-default version. This also requires instance admin to provide the parallel versions on the server.

Future steps could be providing "well known version tags" to be used as version to make it easier to use. The current implementation requires the embedded maps user to know about the versioning system. Having admin configure more developer-friendly tags would make it easier to use. Something like:

• "stable" == for current version
• "next" == upcoming version

Also defaulting the version to stable if requested version was not available would require more work on this.

[ZakarFin]

Keeping this open to gather more experiences and think on the process for updating an instance and how we could help users select the "correct" version when this is enabled.