You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Daniel Kulp (Jira)" <ji...@apache.org> on 2020/05/21 12:44:00 UTC

[jira] [Resolved] (AVRO-2572) [avrocpp] Too restrictive SONAME

     [ https://issues.apache.org/jira/browse/AVRO-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved AVRO-2572.
-------------------------------
    Fix Version/s:     (was: 1.10.0)
       Resolution: Won't Do

As mentioned on the PR, 1.8 and 1.9 are specifically NOT binary compatible with each other.   Thus, renaming the .so to just libavrocpp.so.1 would cause all kinds of issues with upgrades and library versions.     At the very least, the name would have to contain the minor version, like libavrocpp.so.1.9 

> [avrocpp] Too restrictive SONAME
> --------------------------------
>
>                 Key: AVRO-2572
>                 URL: https://issues.apache.org/jira/browse/AVRO-2572
>             Project: Apache Avro
>          Issue Type: Bug
>          Components: c++
>    Affects Versions: 1.8.1, 1.9.0, 1.8.2, 1.9.1
>            Reporter: Laurent Stacul
>            Priority: Major
>
> Hello,
> While I was upgrading Apache Avro from 1.8.2 to 1.9.1, I checked the binary compatibility using RedHat libabigail. If the code was OK which is what I expected from the Semantic Versioning of the project, I did not expect that the binary compatibility check failed due to the soname.
> I checked and found out this point was raised for the C component and fixed there: [https://github.com/apache/avro/pull/239.]
> If the binary compatibility is respected across the major versions of libavrocpp, I would expect
> {code:java}
> SONAME Library soname: [libavrocpp.so.1]{code}
> instead of:
> {code:java}
> SONAME Library soname: [libavrocpp.so.1.10.0-SNAPSHOT.0]{code}
> Do you agree on this ?
> Regards,
> Laurent



--
This message was sent by Atlassian Jira
(v8.3.4#803005)