[
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)
