Dependency version support plan

[leouieda]

Description:

We currently don't really specify the supported versions of many of our dependencies. We've been fine so far but some things are beginning to break, for example the Verde CI has been breaking in Python 3.6 (fatiando/verde#333). I think it's time we adopted a formal policy for dropping older versions of dependencies and implemented testing mechanisms to make sure things work as intended.

Proposal:

I propose we follow NEP 29:

• Support the versions of Python released in the past 42 months (at least 2 minor versions)
• Support the versions of Numpy released in the past 24 months (at least 3 minor versions)

And extend it with:

• Apply the Numpy policy (24 months / 3 versions) to our other run-time dependencies (not development or documentation dependencies)
• Older versions can still be maintained as long as the CI tests still pass and it doesn't cause extra work for us. In other words, we drop them when they become a hindrance.

Implementation:

All projects will need to:

• [ ] Add the policy and expected support time frame to the documentation.
• [ ] Add minimum version numbers to their run-time dependencies (usually in requirements.txt but also in the conda-forge recipe).
• [ ] Add CI jobs that run tests on the minimum supported version of all packages. This can be a single job for each platform Linux/Mac/Windows. The specification can be done by replacing the >= in the requirements file with a == using sed.

Exceptions:

The only exception I can think of is Pooch, which is used by other libraries and should endeavour to support the minimum Python versions supported by these libraries. We should also be more conservative the number of versions supported of dependencies since we don't want to be the cause of broken environments.

Apply to:

• [x] boule
• [x] harmonica
• [x] pooch
• [x] verde

Further instructions:

• Start by opening Pull Requests on each repository listed above.
• Optionally, we can open Issues on each repository if further discussion specific to that repository is needed.
• Mention this Issue on every Issue or Pull Request opened on each opened: Related to fatiando/community#XX
• Check-off the repository on the list above once the Pull Request is merged.
• Close this issue when all items are checked-off.

We want your help!

We know that maintenance tasks are very demanding, so we don't expect a single person to tackle this issue by themselves. Any help is very welcomed, so please comment below that you want to take care of the changes on any repository and we will assign it to you.

[leouieda]

Right now, the timeline we can follow is:

date	python	numpy
Jul 26, 2021	3.7+	1.18+
Dec 22, 2021	3.7+	1.19+
Dec 26, 2021	3.8+	1.19+

Maintaining Python 3.7 for a while longer is unlikely to cause problems so I would propose starting off with Python >= 3.7 and Numpy >= 1.18.

I could use some help collecting the versions of our other dependencies.

[leouieda]

Turned out to be a bit more work than I expected. See fatiando/pooch#280 for a working implementation.

[leouieda]

This is done in Pooch and will be official from the 1.6.0 release planned for Jan 2022.

[leouieda]

Done for Boule in fatiando/boule#111

One problem that arose is the lack of binary wheels for Python 3.10 of older versions of numpy (and likely other packages), which means that it can be difficult to install older numpys on the latest Python. So I opted for running the oldest dependencies on the oldest Python and newer dependencies on the newer Python. These are more likely combinations and reduces the size of the CI matrix quite a bit. Besides, asking for the latest numpy in Python 3.6 was producing 1.19 instead of 1.23 because that's the last version with a wheel anyway.

[leouieda]

All our packages now have this implemented.