Verde just dropped 3.6 for the upcoming 1.8 release. 3.7 works fine for us but maybe it's because of the way we started doing the CI tests. With fatiando/community#40 we can define the earliest supported version of dependencies and on CI I've been making it so we only test the end members. So Python 3.7 with the oldest versions of dependencies and Python 3.10 with the latest versions of dependencies. That avoids issues like this, where we could still support 3.7 while we support versions of xarray that had that support.

That said, according to NEP29 we could have dropped 3.7 by now and support 3.8+ only. So it's up to you what you prefer to do here. But I would really recommend putting in the lower bounds of dependencies in Harmonica soon. I'll try to do that if I can find some time.

For the record: the test failures were fixed in #356 so we are not having any problem with still supporting Python 3.6. And as discussed in the Fatiando Dev Call of 2022-10-26 we agreed that there's no specific reason to do this right now. I'm pushing this for v0.7.0.

@leouieda how do you go about determining the lower bounds for dependencies? Is it just trial and error with the GH Actions tests? Or is there some better, systematic method?

@mdtanker We explain the dependency version support in the documentation pages of most (if not all) libraries. For example, in Harmonica: https://www.fatiando.org/harmonica/latest/compatibility.html#supported-dependency-versions

Basically we try to follow NEP29, which is the Numpy policy for version support. Python has the PEP602 for their own release cycles.

I guess I was asking more about how to determine which versions are compatible, not which versions should be supported (the 24month guideline).

For example, Numpy < 1.20 doesn't work anymore with the Verde dev version due to the 'np.bool' deprecation. How would you figure out that it was specfically Numpy 1.20 which is the oldest compatible Numpy version? Would you just run a matrix of versions on the tests, and see that 1.19 fails but 1.20 passes?

I see what you meant. And yes, most of the times we rely on tests passing or failing to determine if we have an incompatibility with a given version of our dependencies.

Usually incompatibility issues appear with latest versions, when some feature gets deprecated or a breaking change happened upstream. To ensure that our libraries are still compatible with the older versions we just run a CI matrix branch with the oldest supported versions of the dependencies and don't incorporate any new code that would be incompatible with them.

For the example you describe, looking at the deprecations in Numpy's changelog would be enough. But I suspect that Verde is still working with Numpy v1.19. At least the last test on the oldest branch of the matrix passed: https://github.com/fatiando/verde/actions/runs/3656612145/jobs/6179250009 (we could rerun those to get the logs). Did you experience the opposite?