Do we need to bump the shared library version for 2.4.0?

Simon Josefsson simon at
Mon May 26 16:31:31 CEST 2008

In 2.3.x we have moved several symbols from libgnutls-extra to libgnutls
(see complete explanation in the 2.4.0 release notes draft below), but
do we need to bump the shared library version?  No symbols have been
removed from any library libgnutls*, except for the symbols that have
been moved.  libgnutls-extra links to libgnutls.

I see several solutions here:

1) Increment the shared library version of libgnutls*.

   This will cause an unnecessary shared library version break for
   libgnutls, which have only had new functions added to it.  Given the
   problem described in 2) I'm not sure how it could be avoided though.

2) Separate the shared library versions for libgnutls and
   libgnutls-extra, and increment only the libgnutls-extra version.

   This may be the The Right Thing to do, but it causes a new problem:
   an application linking to (2.2.x) may pull in from 2.4.x, which won't work together.  Both and would then provide the same
   symbols.  If the application uses the one from all is
   fine, but it will break of the ones from is used.

3) Don't increment the shared library version at all.

   The justification would be that we haven't removed any symbols, all
   symbols in libgnutls-extra are still available via libgnutls and work
   the same way.  The only thing that would break here is if someone is
   dlopen'ing and calls the openpgp related
   functions.  Strictly speaking I'm not sure this is a valid approach,
   since we HAVE removed symbols from libgnutls-extra.


I'm leaning towards 1) because of the problem in 2) and 3), however I do
realize this will generate a lot of work for our packagers.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls23.txt
URL: </pipermail/attachments/20080526/38a83b3a/attachment.txt>

More information about the Gnutls-devel mailing list