= GEOS RFC 6: Drop support for C++ API and stop shipping the header =

This document proposes to drop the support of GEOS C++ API starting with GEOS 3.8 and to not ship the C++ Headers anymore

||RFC 6:  ||Drop support for C++ API and stop shipping the header||
||Author: ||Regina Obe        ||
||Contact:||lr@pcorp.us    ||
||Status: ||[https://lists.osgeo.org/pipermail/geos-devel/2017-October/thread.html#8050 In Discussion] ||

Past discussions 
[https://trac.osgeo.org/geos/ticket/553 Trac ticket to deprecate]
[https://lists.osgeo.org/pipermail/geos-devel/2017-January/007652.html another request to deprecate and osm2pgsql mess]
[https://lists.osgeo.org/pipermail/geos-devel/2012-June/005861.html more examples about how apps linking directly to GEOS C++ causing problems for other applications]
[https://lists.osgeo.org/pipermail/geos-devel/2017-January/007653.html Pointing out removing ability to use GEOS C++ reduces users freedoms]


We should drop C++ API because we do not have the manpower to guarantee ABI compatiblity from version to version.
Currently osm2pgsql (and before Osmium) and OSSIM were the only ones that use the GEOS C++ API.

Sandro proposed perhaps just making it [https://lists.osgeo.org/pipermail/geos-devel/2017-October/008047.html more noisy].  It is my experience
that most developers ignore noise.  So if we can't support an API full-heartedly I'd just assume drop it.  

It causes all sorts of problems for users relying on the GEOS upstream and novice users will be burned when their code no longer works with newer GEOS.

For GEOS 3.7.0 we should put in a stern warning at configure / cmake that this will be the last minor to support the C++ API so people should start changing their code to not rely on it.