libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Trying to understand libmicrohttpd versioning


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Trying to understand libmicrohttpd versioning
Date: Mon, 13 Feb 2017 17:09:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

Hi!

I think what you're spotting is that I made a mistake in updating the
library revision in the past, and failed to reset CURRENT (or bump AGE).

We are at least 99.9%-compatible with .so.10 / 0.9.37, but there _may_
have been some minor reason to bump the .so-level, not entirely sure
which of the two mistakes I made in retrospect.

Regardless, the only sane way forward at this point is to continue to
stick to the libtool rules, as one cannot sanely go back to .10-levels,
or to .12.0.  Naturally, when we go to .13, we should definitively make
sure to reset CURRENT properly.

Happy hacking!

Christian

On 02/13/2017 04:55 PM, Tomas Heran wrote:
> Hi,
> 
> I'm trying to understand versioning of the libmicrohttpd library, esp.
> when it comes to LIB_VERSION_* variables in configure and the resulting
> -version-info in libtool.
> 
> In our internal repository I'm upgrading from 0.9.37 to 0.9.52, i.e.:
> (0.9.37) libmicrohttpd.so.10 -> libmicrohttpd.so.10.27.0
> (0.9.52) libmicrohttpd.so.12 -> libmicrohttpd.so.12.40.0
> 
> I see that in public releases 0.9.45 and 0.9.46 the LIB_VERSION_AGE has
> not been bumped (stayed the same at 34). That is puzzling as the libtool
> versioning part of the documentation doesn't seem to be mentioning the
> case when one would bump CURRENT, but leave AGE as is.
> 
> This effectively forces programs to be at least relinked (if not
> rebuilt), because the libmicrohttpd.so.10 -> libmicrohttpd.so.10.27.0
> no longer exists and is replaces by libmicrohttpd.so.12 ->
> libmicrohttpd.so.12.40.0.
> 
> Now, I do see some "interfaces" removed, e.g. MHD_connection_close()
> renamed to MHD_connection_close_(), but as far as I understand, that
> function is not a public interface and so as far as the programs using
> this library are concerned, the new version of the library should still
> be backwards-compatible, i.e. programs linked with the older library
> should still work fine without rebuilding and relinking.
> 
> What do I miss?
> 
> Thanks,
> Tomas
> 

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]