Re: proper value for --version-info
* Paul Elliott <pelliott@blackpatchpanel.com> [130815 16:24]:
> version 1.78.00 which was never released, added
> a new symbol beginning swe_ but it did not change
> the meaning of any of the old ones so the
> --version-info for that version should be 1:0:1
>
> I built and checked that version privately, so I
> consider it a "virtual release".
>
> Version 1.79.00 does not add any new swe_ symbols at all over 1.78.
> But new "#define" preprocessor constansts are added,
> and the old functions produce new results for these constants.
Adding new functionality to a function is the same as adding new
functions (only difference is that the failing if the wrong version
is used is uglier).
> In addition some of the 1.78.00 behavior was a bug. It produced
> the wrong answer. This has been fixed so that the 1.79.00
> gives the correct documented answer.
If you consider 1.78.00 never released then it should not matter.
Otherwise even a bugfix can be considered a incompatible change,
but only in extreme situations (programers rarely rely on
documentation but on the actual implementation. If someone
considered that a bug in the documentation and wrote programs
that work with the previous implementation but not the new one,
that *can* make a case for it being a incompatible change).
> Under these conditions what is the proper value for
> 1.79.00 --version-info?
I'd guess either 1:0:1 or 2:0:2 depending on whether you want
to cound 1.78.0 or not.
> The reason for my confusion is this section of Libtool:
>[...]
> The following explanation may help to understand the above
> rules a bit better:
>[...]
> 2. Programs using the previous version may use the new version as
> drop-in replacement, but programs using the new version may
> use APIs not present in the previous one. In other words, a
> program linking against the new version may fail with
> "unresolved symbols" if linking against the old version at
> runtime: set revision to 0, bump current and age.
>[...]
> The first part of 2) is true:
> "Programs using the previous version may use the new version
> as drop-in replacement, but programs using the new version may
> use APIs not present in the previous one."
> but the second part of 2) is not true:
> "In other words, a program linking against the new version may
> fail with "unresolved symbols" if linking against the old
> version at runtime"
> This is not true because the linker never sees the new interface. It
> is hidden by new behavior on calls with new "#define" in constants.
Indeed, that additional "explanation" is missing the case. It's only
a explanation, though.
> I always update the debian/libsweX.symbols file for a new
> release. In this case it shows no new symbols.
If a symbol extends it behaviour, you need to manually increase the
minimum version of that symbol. So in this case you need to set the
minimum version of all those symbols to the current version that
get new additional functionality. (Otherwise you will get wrong
dependencies for a program depending on the new behaviour).
Bernhard R. Link
Reply to: