Versioning Server/Client Modules/Plugins

My current thoughts:

Either:
Server should return as part of the xlf transfer the module version number the server used to generate the xml. The client plugin will then be asked if it can support rendering input in that version format. This leaves module/plugin versioning to the module/plugin author to decide (as, for example, a v1 module might output code which can be rendered by a v2 plugin - or conversely, a v2 modules output may simply provide additional, but not required information, and can therefore be played as a best effort by a v1 plugin.

Or:
Versioning is strictly enforced. The server returns the module version used to generate the xlf entries as part of the xlf. The client will then only load a module of the appropriate version. Q: Does this impact on, for example, template code used in formatting when the server module is upgraded (ie does the user have to freshen the media by loading it in the new server module before it can be displayed).

Or:
Do we introduce the concept of a schema version. So module/plugin versions are irrelivant, but implement a specific schema version. If so, how are these schemas expressed? Do we attempt to enforce them as part of the xlf transfer. If so, how?

In either case, it may be desirable for the server to auto-deploy modules to clients. The JClient has been developed with this in mind - but I think this should be developed on a pull basis from a separate webservice api call such that a non-JClient (should one exist) can opt not to pull modules from the server.

There is also the question of what happens in the event that only a single piece of media cannot be played. Do we blacklist it (as there is no available module?) or do we skip the entire layout?

Dan Garner:
Feedback given at blueprint URL (http://labs.xibo.org.uk/blueprints/Home/blueprints/module-versioning)