Could We add a temporary solution and perhaps change the versioning schema later? I'm asking because all of our c++ based CI builds are failing now.
On Wed, Jul 3, 2019 at 10:51 PM Antoine Pitrou <anto...@python.org> wrote: > > The question: is do we want to maintain a stable ABI? > > Given the number of constraints that we already impose ourselves, I > think I'm -1 on establishing a stable ABI for now. > > So we should probably bump the SO number on each minor release. > > Regards > > Antoine. > > > Le 03/07/2019 à 22:41, Uwe L. Korn a écrit : > > I've documented that some time ago: > https://github.com/apache/arrow/blob/master/docs/source/developers/cpp.rst > > > > I actually wanted to add this to the build but we were breaking the ABI > so often that it would have never been green. > > > > Uwe > > > > On Wed, Jul 3, 2019, at 9:52 PM, Sutou Kouhei wrote: > >> Ruby uses ABI Compliance Checker > >> https://lvc.github.io/abi-compliance-checker/ > >> with a small script: > >> > >> https://github.com/ruby/chkbuild/blob/master/abi-checker.rb > >> > >> There is the official Debian package for it: > >> > >> https://packages.debian.org/search?keywords=abi-compliance-checker > >> > >> In <20c3b917-6f80-ca14-669d-f89e7ec7f...@python.org> > >> "Re: [DISCUSS] C++ SO versioning with 1.0.0" on Wed, 3 Jul 2019 > >> 09:59:15 +0200, > >> Antoine Pitrou <anto...@python.org> wrote: > >> > >>> > >>> Do we have any reliable tool to check for ABI breakage? > >>> > >>> > >>> Le 03/07/2019 à 02:57, Sutou Kouhei a écrit : > >>>> Hi, > >>>> > >>>> We'll release 0.14.0 soon. Then we use "1.0.0-SNAPSHOT" at > >>>> master. If we use "1.0.0-SNAPSHOT", C++ build is failed: > >>>> > >>>> https://github.com/apache/arrow/blob/master/cpp/CMakeLists.txt#L47 > >>>> > >>>> message(FATAL_ERROR "Need to implement SO version generation for > Arrow 1.0+") > >>>> > >>>> So we need to consider how to generate SO version for 1.0.0 > >>>> as the first task for 1.0.0. > >>>> > >>>> See also https://issues.apache.org/jira/browse/ARROW-2522 > >>>> for the current SO versioning. > >>>> > >>>> > >>>> If we may break ABI compatibility each minor version up > >>>> release ("Y" is increased in "X.Y.Z"), we should include > >>>> minor version into SO major version (100, 101 and 102 in the > >>>> following examples): > >>>> > >>>> * 1.0.0 -> libarrow.100.0.0 > >>>> * 1.1.0 -> libarrow.101.0.0 > >>>> * 1.2.0 -> libarrow.102.0.0 > >>>> > >>>> If we don't break ABI compatibility each minor version up > >>>> release, we just use the same SO major version (100 in the > >>>> following examples) in 1.0.0: > >>>> > >>>> * 1.0.0 -> libarrow.100.0.0 > >>>> * 1.1.0 -> libarrow.100.1.0 > >>>> * 1.2.0 -> libarrow.100.2.0 > >>>> > >>>> > >>>> I choose 1XX as SO major version because we already use > >>>> 10-14 for SO major version. We should not use them in the > >>>> future to avoid confusion. So I choose 1XX in the above > >>>> examples. > >>>> > >>>> > >>>> Any thoughts? > >>>> > >>>> > >>>> Thanks, > >>>> -- > >>>> kou > >>>> > >> >
