From: "Ondřej Lysoněk" <olysonek@redhat.com>
To: Jean Delvare <jdelvare@suse.de>
Cc: linux-hwmon@vger.kernel.org
Subject: Re: libsensors soname bump
Date: Mon, 17 Dec 2018 10:46:43 +0100 [thread overview]
Message-ID: <514c8587-ccf3-f7af-b88d-744add6f1da2@redhat.com> (raw)
In-Reply-To: <20181216124344.49d06b69@endymion>
Hi Jean,
On 16. 12. 18 12:43, Jean Delvare wrote:
> Hi Ondřej,
>
> You have recently released lm-sensors 3.5.0 with a new soname for
> libsensors:
>
> -LIBMAINVER := 4
> -LIBMINORVER := 4.0
> +LIBMAINVER := 5
> +LIBMINORVER := 0.0
>
> -#define SENSORS_API_VERSION 0x440
> +#define SENSORS_API_VERSION 0x500
>
> This is declaring the new library as incompatible with the previous
> version, meaning that distributions will have to build and ship both
> libsensors4 and libsensors5 for a long time until all applications have
> been updated and rebuilt to link with the new library. This is a
> significant effort for the whole community and should only be done when
> necessary.
I thought there was an ABI change, which would warrant a soname bump. Or
am I wrong in thinking that? I was mistaken however and I'm sorry about
that, there was no ABI change.
I don't see why distributions would have to ship two versions of the
library. The *name* of the library didn't change, it's still libsensors
(not libsensors4 or libsensors5).
[~/git/lm-sensors]$ make
...
[~/git/lm-sensors]$ ls lib/ | grep libsensors.so
libsensors.so
libsensors.so.5
libsensors.so.5.0.0
So all distros need to do is rebuild dependent packages. No changes to
other packages should be required.
Am I missing something?
Thanks.
Ondra
>
> In this specific case, I can't see what warranted such a change of
> major library version change. From
> lm-sensors/doc/developers/release_checklist:
>
> Remember: update main number when interface changes, minor if new
> functionality is added, and patch if only bugs are fixed.
>
> In this case I can only see new functionality added, there is no
> interface change. Therefore the correct value for SENSORS_API_VERSION
> was 0x450, not 0x500. This would avoid the parallel maintenance and
> installation of 2 versions of the library for several years to come.
>
> Would you consider quickly releasing lm-sensors 3.5.1 with the proper
> library version number, to save all that work to all application
> authors/maintainers and distribution package maintainers?
>
> Thanks,
>
next prev parent reply other threads:[~2018-12-17 9:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-16 11:43 libsensors soname bump Jean Delvare
2018-12-17 9:46 ` Ondřej Lysoněk [this message]
2018-12-17 10:35 ` Ondřej Lysoněk
2018-12-17 10:59 ` Jean Delvare
2018-12-17 11:27 ` Aurelien Jarno
2018-12-17 11:48 ` Ondřej Lysoněk
2018-12-17 12:06 ` Ondřej Lysoněk
2018-12-17 10:48 ` Jean Delvare
2018-12-18 17:06 ` Ondřej Lysoněk
2018-12-19 15:10 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=514c8587-ccf3-f7af-b88d-744add6f1da2@redhat.com \
--to=olysonek@redhat.com \
--cc=jdelvare@suse.de \
--cc=linux-hwmon@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox