You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Miguel Ángel Herranz Trillo (JIRA)" <ji...@apache.org> on 2013/11/27 11:23:41 UTC

[jira] [Commented] (THRIFT-2270) Faulty library version numbering at build or documentation

    [ https://issues.apache.org/jira/browse/THRIFT-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833630#comment-13833630 ] 

Miguel Ángel Herranz Trillo commented on THRIFT-2270:
-----------------------------------------------------

Thanks for the explanation, I understand that also the generated code should be taken in account. 

But to me it seems that there is still a lack of information about the versioning scheme.

Then, what are the 3 numbers for? I mean, maybe they could be used like <protocol>.<generated_code>.<implementation_bugfix>, so the last number is just a fix in the library that doesn't add any change in the external interface (neither protocol nor generated code).

I know that to be in the safe side, since C++ red line between implementation and interface is very thin, it could be correct to increase every 2nd version number in 99% of version change to indicate a change in the <generated_code>, for example.

But at least, for the remaining 1%, the 3rd version number could be used instead, so it will have a purpose in life :)

If not, I don't see any reason to just have <protocol>.<generated_code> instead of 3 numbers whose meaning is not described in the documentation.

I think that things should be simplified whenever possible. Maybe there is another reason (like limitation of building tools to manage just 2 numbers instead of the "normal" 3-tuple) ... I don't know.

Thanks anyway, since I understand that this is not a major issue for thrift. Maybe an update/clarification in documentation is enough.




> Faulty library version numbering at build or documentation
> ----------------------------------------------------------
>
>                 Key: THRIFT-2270
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2270
>             Project: Thrift
>          Issue Type: Bug
>          Components: Build Process, C++ - Library, Deployment
>    Affects Versions: 0.9.1
>         Environment: Linux
>            Reporter: Miguel Ángel Herranz Trillo
>            Assignee: Jake Farrell
>            Priority: Minor
>              Labels: build, documentation
>
> The shared libraries generated for C/C++ under Linux (.so files) have a SONAME that includes the full version number.
> For example:
> {code}
> # objdump -p libthrift.so | grep SONAME
>  SONAME               libthrift-0.8.0.so
> {code}
> Since the compilation process will make any program compiled against a library to depend on the SONAME, in the case of Thrift library, the program will depend on the full version number.
> The program will fail if some other different Thrift library version is provided instead, despite it can be a minor improvement or a bug fix that doesn't break the external interface.
> For example, if external interface of 0.8.0 is the same as 0.8.1 or even 0.9.1 (since it may happen that only the first number represent changes in the dynamic linking or protocol interface), then we could expect that a program will depend on a SONAME with the format libthrift.so.0 and that both version 0.8.0 and 0.9.1 shared library binaries provides the same SONAME equal to libthrift.so.0
> I haven't found any document about the versioning scheme in Thrift or the compatibility between versions (maybe I didn't search enough, so sorry in that case).
> So, if that document does not exist, I think it should be created. 
> And also, in case that some of the version numbers are just used for changes that doesn't imply changes in the ABI or the Thrift protocol itself, the numbers should be removed from the SONAME of the Thrift library binary.



--
This message was sent by Atlassian JIRA
(v6.1#6144)