[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
>
signature.asc
Description: OpenPGP digital signature