Hi, John, على الثلاثاء 31 أيار 2016 03:01، كتب John Marshall: > On Mon, 2 May 2016 21:54:49 -0700 Afif Elghraoui <a...@debian.org> wrote: >> This seems to happen with every htslib upgrade in the past few releases. >> bcftools builds have also been breaking as a result and I was a little >> confused. Aren't backwards-compatibility breaks supposed to be indicated >> by soname bumps? Or is this because samtools, bcftools, and htslib are >> all maintained by the same group, so they rely on the unstable internal >> interfaces? > > Afif, please explain these comments if you would like upstream to listen to > you in future. > > In fact we take htslib API/ABI compatibility very seriously. >
I sincerely apologize that this comes across as offensive-- it truly wasn't intended that way. I was (and still am) somewhat confused about this subject, thoug. My confusion is mostly about the tightness of the htslib/samtools/bcftools interdependence and their coordinated releases. I have never been worried about your breaking externally developed programs. Anyway, here is the context for my comments. The first version of bcftools in Debian was 1.2. After both htslib upgrades since then, bcftools builds would fail until the matching version was uploaded: bcftools 1.3 build failure after introduction of htslib 1.3.1: https://ci.debian.net/data/packages/unstable/amd64/b/bcftools/20160425_215548.autopkgtest.log.gz bcftools 1.2 build failure after introduction of htslib 1.3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813465 My mention of internal interfaces was based on my impression of what's described in this thread: <https://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-January/038827.html> Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
