Dropping support for 3.5 would raise issues for people on Ubuntu 16. As it's still one year in official support, many are still using it. So I'd prefer working with version conditionals (I set up already some macros for that) instead of just dropping support.

Same goes for Python 3.5.

Ok. Maybe we could make the recommended versions more clear up front and the deprecation plan for versions of GEOS (i.e., that it is tied to the version of GEOS and Python available on the currently-supported LTS of Ubuntu). I.e., "While GEOS 3.5 will remain minimally supported until Ubuntu 16 reaches end of life, we recommend you use at least GEOS 3.6 to take advantage of newer features or bug fixes..."

Then within individual functions that depend on newer versions, we document such in their docstrings and explicitly check version and raise appropriate errors. Other than bug fixes that were introduced into GEOS 3.6, I think the only new feature pending is nearest that depends on >=3.6, but there are other things on the horizon that may need at least that version or newer.

There are also a couple of functions (isCCW, and others) that were introduced to the C API after 3.5. We should probably work with a @minimum_geos_version("3.5") decorator that replaces the function with a dummy if necessary.

In numpy / pydata land they made an information proposal with advice on how long to support versions (here specifically python and numpy), which opted for a shorter support period: https://numpy.org/neps/nep-0029-deprecation_policy.html

(not that all projects in the pydata community (already) follow that, though)

Now, as long as in practice is becomes not a too big burden to support the older versions, I am fine with keeping them (but would also be happy with dropping. But I mainly live in conda-land, so there I have access to recent version anyway).

I'll also add that I think GEOSSTRtree_nearest_generic_r was added in 3.6, so I think #111 would require this change (or some type of decorator, as @caspervdw suggested).

It would make our lives easier for sure to drop support for earlier versions. On the python and numpy side, I am 👍 on following the suggestions done by https://numpy.org/neps/nep-0029-deprecation_policy.html

On the GEOS side, I am still a bit doubtful. I know for a fact that many webservers are still on Ubuntu 16, which is fine, but they also have GEOS 3.5 there. I think it is logical that the "website world" has the tendency to "stick with what works", more than the pydata community.

At the same time, we will need the decorator approach anyway for GEOS differences between 3.6 and 3.8. So I don't think it will cost us a lot to keep 3.5 there.

At the same time, we will need the decorator approach anyway for GEOS differences between 3.6 and 3.8. So I don't think it will cost us a lot to keep 3.5 there.

+1

@brendan-ward Do you agree with deciding on Python >=3.6+, Numpy >=1.15+, and GEOS >=3.5 ?

I am actually very happy with dropping Py3.5. f-strings and type annotations, here we come!

Yes - agree on those minimums. Feel free to close this PR at any point; it's superseded by your #120

For the python / numpy versions, we might want to check with Shapely before actually updating code to use those new features (if there is no agreement there about this, that would then only make it harder to upstream the code).

(will open an issue about that there)

Closing through #125

With Ubuntu 16.04 about to reach EOL in a few days, it's time to bump the minimum required version of GEOS to 3.6.

@brendan-ward do you want to revise this PR?