[gdal-dev] GDAL 3.1.0 RC2 available

[Sebastiaan Couwenberg]

On 5/3/20 8:10 PM, Even Rouault wrote:
>> Why wasn't the SONAME bumped to reflect the ABI breakage?
> 
> For me, SONAME bump was meant for the C ABI. I don't think this was intended for the C++ 
> one.

They share the same library, so the SONAME covers both.

If you don't want that, then two libraries need to be built with their
own library versioning.

That would allow for more granular rebuilds of rdeps as the C++ using
ones will need to be rebuilt for X.(Y+1) versions but the C using ones not.

>> We dropped the virtual dependency that required rebuilding for every
>> GDAL version change because you claimed that this wasn't required any more.
> 
> 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
> 
> 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.
> """
> 
> 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 ?

Yes. If the ABI of the library is not compatibly any more, i.e. rdeps
needs to be rebuilt, then the SONAME needs to be bumped.

> 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 ?

Yes, as that bumps the SONAME to libgdal.so.27, which signals that rdeps
need to be rebuilt.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1