[geos-devel] GEOS 3.9.0 Released

[Daniel Baston]

I think the role of GEOS is limited to documenting the stability of its
interfaces. We are clear that the C++ interface can change between releases
whereas changes to the C API are additive only. Projects that use GEOS
should choose the interface that best meets their needs. If you are using
only the most common functionality of GEOS, want to distribute binaries in
a Linux/BSD distribution, and don't want to have to update your code to
accommodate API changes? Probably you should use the C API. Are you using
more obscure functionality, vendoring GEOS, statically linking, or happy to
update your code to accommodate API changes? Maybe use the C++ API.

Dan

On Fri, Jan 29, 2021 at 3:31 PM Greg Troxel <gdt at lexort.com> wrote:

>
> Daniel Baston <dbaston at gmail.com> writes:
>
> >>
> >> Some headers I see were installed as a facility for C++ library users.
> >> Nowadays we discourage those users so I don't see any big problem with
> >> them being removed (like opBuffer.h and io.h)
> >>
> >
> > I think this comment is about https://trac.osgeo.org/geos/ticket/999.
> That
> > probably should have been in the NEWS if it was not.
> >
> > Because listserv chatter sometimes becomes a source of documentation for
> > users, I think it's important to point out that the GEOS project ("we")
> has
> > no policy of discouraging use by C++ library users.
>
> That seems to be a policy change that I missed.  We had this discussion
> quite a while ago and the README said the C++ interface shouldn't be
> used after that discussion.  I then updated the comment in the geos
> pkgsrc package to note that it was a bug for other packages to use the
> C++ interface, and thus there was no need to consider the geos package
> to have had an ABI change because of actual ABI changes or the usual C++
> "C++ is so complicated we have no way to know if the ABI changed, so
> change the shlib version, and then we know it did!" always-on ABI change.
>
> Now the README just says that the C++ interface is unstable, to the
> point where changes in it are not worthy of being mentioned in NEWS, let
> along having some API compat and transition strategy.  That is just
> about equivalent to a recommendation not to use it.
>
> I should point out that I don't really have an agenda about whether the
> C++ interface should be recommended for use.  But as I see it, there
> are only two reasonable options:
>
>   1) recommend that the C++ interface not be used
>
>   2) say that use is ok, and have an API stability plan where code
>   written to each release's API is expected to continue working for some
>   significant period of time (perhaps 2 years) in future releases after
>   an API element is deprecated (Note that to me ABI stability is not
>   that big a deal.)
>
>   Perhaps, say it's ok to use the C++ API as long as you don't release
>   your code :-)
>
> In all seriousness, packaging systems are put into a bind when a program
> B depends on interface A, A turns out to be unstable and B doesn't get
> instantly updated.  Any plan for what's usable and API stability has to
> take that into account, for packages that actually are used by other
> packages.  This is basically a summary of the view that prevailed in the
> last discussion, as I remember it, which is fuzzily.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20210129/684d6e0a/attachment.html>