[geos-devel] RFC 9: Restore C++ API as public API

[Andrew Bell]

On Fri, May 17, 2019, 8:53 AM Regina Obe <lr at pcorp.us> wrote:

> > On 5/17/19 3:23 PM, Andrew Bell wrote:
> > > Frequent, breaking API changes seem a problem. ABI changes seem more
> > > like a small annoyance. I can understand how a stable ABI would be
> > > nice, but I personally don't think it's more important than a good
> > > interface for library users.
> >
> > And that's the difference in perspective between a developer and
> distribution
> > packager.
> >
> > Kind Regards,
> >
> > Bas
> >
> > --
> >  GPG Key ID: 4096R/6750F10AE88D4AF1
> > Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> [Regina Obe]
> Exactly.  These days my sensitivities like more on the packaging side than
> the development side.
> If GEOS was a fledgling project I would be fine with broadcasting yeh we
> have a public C++ API.
>
> The thing is you can still use the C++API, we are just making it clear
> that you are on your own, which mloskot claims C++ developers know already.
>
> Well guess what? the users/developers downstream of some project that
> depends on GEOS may not know that, and then they'll be screwed when we
> change...


How so? Shared libraries are versioned. If you're not rebuilding against a
new API, the soname should guarantee usability.

Right now the C++ API I feel is more in flux than ever, so the last thing I
> want is people relying on it especially now while we are making major
> changes to it.
>

Why are you doing this? If you want to significantly change the interface,
why not make a new one in a new namespace, for example? This would preserve
backward compatibility for existing users.

This really strikes me as a design issue, rather than one of packaging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20190517/4e00c648/attachment.html>