Today, zhmcclient does not document HMC/SE version or feature dependencies. We simply let the functions fail on the HMC when they are not yet supported. That is inconvenient for users and also it is not always obvious that a too old version of HMC or SE is the source of the problem.
This problem is aggravated by the fact that meanwhile there are different mechanisms for version dependencies:
HMC version
HMC API version
SE version
FW features (the older feature concept, e.g. storage mgmt feature)
API features at the HMC and SE level (the newer feature concept, e.g. environmental-metrics)
Add a section "Version dependencies" to the "Introduction" chapter to explain how we document these version dependencies. The default if nothing is documented is that there are no such version dependencies.
For each class and/or method/property that has version dependencies, add a paragraph "Version dependencies" that shows the HMC version range or SE version range. Note that HMC API version dependencies, API feature dependencies, and FW feature dependencies are shown via their corresponding HMC or SE versions, to keep it simple for users.
Today, zhmcclient does not document HMC/SE version or feature dependencies. We simply let the functions fail on the HMC when they are not yet supported. That is inconvenient for users and also it is not always obvious that a too old version of HMC or SE is the source of the problem.
This problem is aggravated by the fact that meanwhile there are different mechanisms for version dependencies: