Allow check_version to require only minimum version

[philipstarkey]

Original report (archived issue) by Russell Anderson (Bitbucket: rpanderson, GitHub: rpanderson).

---

At present, check_version requires the version of a dependency be equal to or greater than a particular version (at_least), and less than a higher specified version (less_than). This proposal would permit check_version to only require the version of a dependency be at_least or later, with no upper bound on the required version.

Reasoning: Won't have to keep updating check_version calls in line with packages that change minor version number regularly. I think the check_version is more of a hindrance than a help here, e.g. if a user updates packages in their environment and the new version exceeds less_than specified in a check_version call of a labscript module's _init_.py, then that module won't start. This may elicit the user to post an issue (diligence), downgrade the dependency (apathy), or give up (despair). If the issue is reported, checking the higher version of the dependency may not be exhaustive as we don't have unit tests, etc. Instead, this proposal permits (but does not demand) a "works with dependency vX or later until we know better" approach. If there is a real incompatibility with a newer version of a dependency, this will likely be detected in real-world use. The issue can then be resolved expeditiously if reported.

[philipstarkey]

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

---

I agree with this. Furthermore, when specifying a maximum version, the error should be a warning unless some extra argument like strict=True. That way apps can not break unnecessarily, but can still warn that code is untested with the newer versions. And then we should continue to specify the next version up as the maximum for projects that follow semver, as it indicates possible breakage and will trigger the warning. But it does not make sense to provide an upper limit for projects that do not follow semver, and it is better manners to print a warning instead of crash if you are merely unsure if code works as opposed to sure that it does not.

I will make this change prior to bumping the zprocess version to 3.0 since basically all our code is already compatible with zprocess 3.0 (unreleased, but I know what will be deprecated and we have already stopped using it) even though it says it is not, and there is no good reason to force everyone to upgrade apps just because they upgraded zprocess.