[gdal-dev] GDAL 3.1.0 RC2 available

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

[I'm behind in dealing with gdal, but otherwise would be in the same
boat as Bas]

> There has been obviously a misunderstanding. The rule we follow is that:
> - between GDAL X.Y.Z and X.Y.(Z+1), both C and C++ ABI are stable
> - between GDAL X.Y and X.(Y+1), the C ABI is stable, but the C++ one not

That's a perfectly ok policy.

> And this is what we have in our release procedure:
> """
> 4) Update LIBGDAL_CURRENT/REVISION/AGE macros in GDALmake.opt.in.
>    - For a release with no interface changes just bump REVISION.
>    - Adding interfaces, bump CURRENT/AGE, set REVISION to 0.
>    - Deleting interfaces / compatibility issues - bump CURRENT, others to zero.
> """

This doesn't make sense.  The current/revision/age needs to be handled
differently for the C library and the C++ library, because in feature
releases one of them does not have an ABI break and the other one does
have an ABI break.  They will then not have the same shlib major
numbers, which is an obvious consequence of the above versioning policy.

> So as interfaces were added, I bumped CURRENT/AGE and set REVISION to 0.
> But maybe "compatibility issues" should also be understood to changes that affect the C++ 
> ABI ?
>
> I'm not sure about the resolution here. Should I do a RC3 that sets
> CURRENT/REVISION/AGE to 27/0/0 ? Would that help ?

I think it would be really unfortunate to break the C ABI as a side
effect.  That would change your policy above that there is (perhaps) an
ABI break on feature releases.

Even better would be to keep the C++ ABI stable.  I'm not really clear
on the details here, but it seems that  C++ and stable  tend not to go
together, and I have heard people (not necessarily here) express that it
is too hard to know if the C++ lib ABI has changed or not.