Device code should have a version associated with it

[philipstarkey]

Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

---

In moving towards a more siloed set of device code, that may or may not be housed within labscript_devices module and/or may not be committed to the labscript_devices master repository, I think that we should tag devices code with versions. I think preferably, this would be a semver string or tuple as an attribute of the relevant class that labscript/BLACS(GUI/Worker)/runviewer instantiates (I think all classes in a given commit would be expected to have the same version). Labscript would be expected to save this information in the connection table properties.

We could then use standard semver logic to determine shot compatibility (although, it could be argued that you might want to restrict shots from running if they were compiled using a different version due to the potential interplay of a bug fix applied only to one side of labscript and BLACS, in which case perhaps the strictness of the comparison should be configurable via the connection table plugin preferences window)

[philipstarkey]

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

---

Agreed. I'm doing something like this with the new DAQmx class. I think a single version saved as a connection table attribute, and a line in the BLACS and runviewer classes that checks it's not a major version higher than what they are is sufficient.

I would forgo configuration in BLACS for the moment and just be aggressive about bumping the major version number and requiring recompilation. We can revisit this as needed.

I might aim to wrap the version checking functionality into a simple function in labscript_devices like check_version but not for imports, and with an error message talking about recompilation or whatnot. At the moment I have this in the DAQmx classes but I should make it available to other devices.

A separate issue is stability of the interface of device classes for the purpose of experiment scripts. It's like we have "binary compatibility" (will the shot file run the same?) and "source compatibility" (will the experiment script compile to a shot that will run the same?) So if we're bumping version numbers based on compiled-shot compatibility, semver logic will not apply for working out whether an experiment script will still compile. But I think it would be premature to address this at the moment since it has not been a problem in practice yet.