Version Number Policies of Depencies

A brief overview of the policies our dependencies (seem to) have when it comes to increasing version numbers (and hence, which restriction should be put into setup.cfg, if any):

major version release: a.y.z -> b.0.0 minor version release: x.a.z -> x.b.0 patch release: x.y.a -> x.y.b

dependency version policies:

• pytest ( https://docs.pytest.org/en/latest/changelog.html#changelog )
  • minor releases do not change public api (except for deprecations); they might change internal api
  • restrict major version
• sympy ( https://github.com/sympy/sympy/wiki/Release-Notes-for-1.3 )
  • api changes in minor releases
  • restrict minor version
• numpy ( https://docs.scipy.org/doc/numpy/release.html )
  • patch releases (a.b.c -> a.b.d) seem to be safe
  • minor version change returned values and sometimes function arguments
  • minor version releases sometimes drop support for older python versions (which might still be supported by qupulse)
    • not a problem as long as qupulse is compatible with older version s.t. there is at least one working dep.-version to support all supported python versions of qupulse
  • restrict minor version
• cached_property ( https://pypi.org/project/cached-property/ )
  • seems to follow semantic versioning conventions
  • minor version releases drop support for older python versions (which might still be supported by qupulse)
  • restrict major version
• matplotlib ( https://matplotlib.org/3.0.0/api/api_changes_old.html )
  • minor version releases change api
  • restrict minor version
• pyvisa ( https://github.com/pyvisa/pyvisa/blob/master/CHANGES )
  • restrict major version
• pytabor (?)
  • restrict minor version
• teaawg (?)
  • restrict minor version
• gmpy2 ( https://gmpy2.readthedocs.io/en/latest/intro.html#gmpy2-versions )
  • restrict minor version