Re: freeze exceptions: qpdf, tiff
Julien Cristau <jcristau@debian.org> wrote:
> On Fri, Aug 20, 2010 at 16:27:13 -0400, Jay Berkenbilt wrote:
>
>> For qpdf, this is a new upstream version that is binary compatible with
>> the old one. qpdf is isolated in the dependency tree (no other packages
>> depend on it), and I am upstream, so I can definitely vouch for the fact
>> that the changes were relatively minor and should be very safe.
>>
> I see new API but no shlibs bump?
New API doesn't require a shlibs bump. Changed or removed API requires
a shlibs bump. 2.2.0 adds several new functions. The only function
that changed incompatibly was
QPDFWriter::disableIncompatbleEncryption(float), which is a private
method in the QPDFWriter object. No external code could call that
method, so it can't be an unresolved symbol anywhere, so changing it
does not require a shlibs bump. I use libtool to manage the shlibs.
CURRENT,REVISION,AGE for 2.2.0 is 4,0,1. For 2.1.5, it was 3,4,0. This
is consistent with new API having been added but no callable API having
been changed or removed.
To be absolutely certain, I built qpdf 2.1.5 from source, swapped its
native libqpdf.so.3.0.4 with a copy of libqpdf.so.3.1.0 (renamed to
libqpdf.os.3.4), and ran qpdf's very thorough test suite. The 2.1.5
qpdf's test suite passes when run with the 2.2.0 qpdf's shared library
with the exception of the fact that the test suite reports incomplete
coverage on the new API (which is, of course, not exercised by the 2.1.5
test suite). So (assuming you trust the thoroughness of the qpdf test
suite), this also confirms that the ABI has not been broken.
Are you seeing something different from this? If so, please let me
know. I'm also interested to know what you're using to determine
whether there are ABI changes. Thanks for being so thorough.
--
Jay Berkenbilt <qjb@debian.org>
Reply to: