Minimum versions for optional libraries

[crusaderky]

In CI there are:

• tests for all the latest versions of all libraries, mandatory and optional (py36, py37, py37-windows)
• tests for the minimum versions of the mandatory libraries only (py35-min)

There are no tests for legacy versions of the optional libraries.

Today I tried downgrading dask in the py37 environment to dask=1.1.2, which is 6 months old...

...it's a bloodbath. 383 errors of the most diverse kind.

In the codebase I found mentions to much older minimum versions: installing.rst mentions dask >=0.16.1, and Dataset.chunk() even asks for dask>=0.9.

It think we should add CI tests for old versions of the optional dependencies.
What policy should we adopt when we find an incompatibility? How old a library should be not to bother fixing bugs and just require a newer version? I personally would go for an aggressive 6 months worth' of backwards compatibility; less if the time it takes to fix the issues is excessive.
The tests should run on py36 because py35 builds are becoming very scarce in anaconda.

This has the outlook of being an exercise in extreme frustration. I'm afraid I personally hold zero interest towards packages older than the latest available in the anaconda official repo, so I'm not volunteering for this one (sorry).

I'd like to hear other people's opinions and/or offers of self-immolation... :)

[shoyer]

Today I tried downgrading dask in the py37 environment to dask=1.1.2, which is 6 months old...

Yikes, we should fix this.

It has not been hard to ensure that older version of NumPy and pandas work. The key thing is CI tests that verify things as PR goes in. If work-arounds for old versions are hard, then we bump minimum required dependencies.

Probably the best place to start would be adding a CI build with pinned versions of the oldest required versions that works today, and then looking if there are simple fixes that will let us downgrade project like dask. It's not worth a huge effort, but it's not very user friendly for everything to broken with old versions of optional dependencies either.

[crusaderky]

How does this sound as a rolling policy?

• Python: latest 2 major versions published in official anaconda releases (as opposed to just the conda repository), plus the latest major version available version in conda-forge. Latest available minimum versions. This today translates to =3.6 and =3.7 (with no minor versions, so actually 3.6.7 and 3.7.4); 3.8 to be added as soon as conda-forge rebuilds its own stack with it.
• numpy, pandas, scipy: latest major version at least 1 year old; latest available minor version (which may be newer than 1 year old). Today this translates to numpy=1.15, pandas=0.23, scipy=1.1.
• all other non-NEP18 packages: 6 months old major versions, or the latest available in the anaconda (not conda-forge) repository if it exists, whatever is older
• NEP18 packages (sparse, pint, etc.): very latest available only, at least until the technology has reasonably matured across the whole ecosystem. This extends to dask when used to wrap NEP18 arrays. numpy >=1.17.
• In all cases: older versions than those stated by the above policy can remain officially supported indefinitely, but only as long as doing so can be achieved trivially and doesn't slow development down.

[shoyer]

it would be nice to try to follow the guidelines in NEP-29: https://numpy.org/neps/nep-0029-deprecation_policy.html

[crusaderky]

@shoyer that sounds sensible, but only covers python and numpy. What about the rest?

[crusaderky]

Revised proposal (in parenthesis: minimum version if this policy were to be applied right now):

• Python: NEP-29; 42 months (>=3.6)
• numpy: NEP-29; 24 months (>=1.14)
• pandas: 24 months (>=0.20)
• scipy: 24 months (>=0.19)
• NEP18 packages (sparse, pint, etc.): very latest available only, at least until the technology has reasonably matured across the whole ecosystem. This extends to dask when used in conjunction with any of these packages. numpy >=1.17. A very recent version of pandas may also be required if necessary.
• all other packages: 6 months or the latest available in the anaconda (not conda-forge) repository if it exists, whatever is older.

Note: patch versions are not pinned. This means that the minimum python version that is guaranteed to work is actually 3.6.7 or 3.6.9, not 3.6.0.

What are people's thoughts?

It may also be a cool idea to write a script that parses the requirements yml files and generates .rst documentation out of them.

[crusaderky]

I slightly misinterpreted NEP-29. The above should be rectified:

pandas: 24 months (>=0.21)
scipy: 24 months (>=1.0)

[shoyer]

Thanks for putting this together -- this looks good to me!

We can revise if any of they cause us trouble. In particular, pandas has the most stability issues, so it might be a little annoying to try to maintain two years of support.