Handle differences in software versions between instrument and GUI

[IsabellaRey]

As a developer, I want to manage the software versions deployed on the instruments compared to the GUI and handle cases where the instrument's API is not in sync with what expected by the GUI.

As part of this ticket, we should come up with a way of managing this.

This could be as simple as having a PV containing the software version of the blockserver (or API version).

The motivation behind this ticket originates from #1053, where changes in the synoptic PV names meant that changes of the GUI and the blockserver had to be merged and deployed together.

[John-Holt-Tessella]

Issues to consider: 1) Do we allow GUIs to run with older/newer versions of the instrument API 2) If yes how long for 3) If not indefinitely how do we get rid of code which is for old versions of a GUI

[kjwoodsISIS]

We agreed that newer clients should run with older versions of the instrument API. Older clients should decline to run with newer versions of the instrument API and should advise the user to upgrade to the most up to date client.

[kjwoodsISIS]

Come up with a provisonal design. Implementation issue to come later.

[AdrianPotter]

From a discussion between @IsabellaRey, @John-Holt-Tessella and me. How do we update the current architecture to implement some form of adapter which will allow us to get output from a PV based on the instrument and version number. We'd like to avoid yet more layers of observables. I attach the whiteboard snapshot for posterity:

[John-Holt-Tessella]

Initially we are not going to be compatible between older instrument and newer clients. But see https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Deployment

[kjwoodsISIS]

Reviewed https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Deployment. Also created issues #1263, #1264, #1265, #1266, #1267 to handle specific aspects of implementation.