There may be a need to ensure that a StateCU dataset is only run with software that is the appropriate version. This could prevent confusion for users.
I have been adding #@require comments to TSTool and StateDMI test command files and also used for the recent well processing command files for ArkDSS StateDMI. The basic idea is to use a comment like the following. Note that this syntax is used in TSTool and is one generation ahead of StateDMI. I'm updating StateDMI similarly. The end of the check is implemented in the specific software and can be any check.
#@require app StateDMI version >= 1.2.3
#@require datastore HydroBase version >= YYYYMMDD
This allows the software (if it understands these comments) to do the check and exit out if the requirement is not met.
The same approach could be taken for StateCU executable to check that the executable being used is consistent with a version that was used to develop the dataset. There may also be cases where a dataset is frozen/archived (such as for court case, etc.) and an older version of the executable needs to be ensured. At the moment this won't be possible unless the older code is recompiled to check the requirement.
If a wrapper program like statecu.cmd is used to actually run the software, then the wrapper could also be smart enough to try to locate the correct version of the software. The concept of a wrapper or launcher program is similar to what Python does on Windows:
Finally, this concept could be extended to include other properties. For example, TSTool and StateDMI use @enabled False and @expectedStatus Failure in testing.
There may be a need to ensure that a StateCU dataset is only run with software that is the appropriate version. This could prevent confusion for users.
I have been adding
#@require
comments to TSTool and StateDMI test command files and also used for the recent well processing command files for ArkDSS StateDMI. The basic idea is to use a comment like the following. Note that this syntax is used in TSTool and is one generation ahead of StateDMI. I'm updating StateDMI similarly. The end of the check is implemented in the specific software and can be any check.This allows the software (if it understands these comments) to do the check and exit out if the requirement is not met.
The same approach could be taken for StateCU executable to check that the executable being used is consistent with a version that was used to develop the dataset. There may also be cases where a dataset is frozen/archived (such as for court case, etc.) and an older version of the executable needs to be ensured. At the moment this won't be possible unless the older code is recompiled to check the requirement.
If a wrapper program like
statecu.cmd
is used to actually run the software, then the wrapper could also be smart enough to try to locate the correct version of the software. The concept of a wrapper or launcher program is similar to what Python does on Windows:https://stackoverflow.com/questions/50896496/what-is-the-difference-between-py-and-python-in-the-terminal
Finally, this concept could be extended to include other properties. For example, TSTool and StateDMI use
@enabled False
and@expectedStatus Failure
in testing.