[geos-devel] GEOS 3.9.0 Released

[Greg Troxel]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20210129/f7aa3728/attachment.sig>