From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH 10/11] libmpathpersist: add linker version script
Date: Fri, 25 Sep 2020 17:10:22 -0500 [thread overview]
Message-ID: <20200925221022.GB3384@octiron.msp.redhat.com> (raw)
In-Reply-To: <d41328cd56bc65f9506d9a7f7548593aa07d775a.camel@suse.com>
On Fri, Sep 25, 2020 at 09:52:51PM +0200, Martin Wilck wrote:
> On Thu, 2020-09-24 at 23:00 -0500, Benjamin Marzinski wrote:
> > On Thu, Sep 24, 2020 at 03:36:43PM +0200, mwilck@suse.com wrote:
> > >
> > > --- /dev/null
> > > +++ b/libmpathpersist/libmpathpersist.version
> > > @@ -0,0 +1,20 @@
> > > +LIBMPATHPERSIST_0.8.4.0 {
> >
> > I have a question about this version. Do you plan on bumping this
> > each
> > time a new release is tagged? It seems like we only ever want to
> > change
> > the version if we actually change the ABI. Or is 0.8.4 just because
> > that's the relesae where we started this?
>
> That was the idea, yes. And the last digit is because we'll have to
> bump it between releases from Christophe. It makes sense for
> libmultipath's rapidly changing ABI; much less so for libmpathcmd and
> libmpathpersist, which are meant to be stable. I am open for discussing
> these numbers; if you prefer, we might as well use LIBMPATHPERSIST_1.0.
>
> I admit I haven't thought about what would happen once Christophe makes
> a new release. Probably, nothing - afaics it's impossible to add a new
> version without any new symbols, and *renaming* an existing version is
> bad; it would introduce artificial incompatibility.
>
> So libmultipath from multipath-tools 0.8.5 would still have a 0.8.4.x
> ABI; only the first change after 0.8.5 would get a 0.8.5.1 number. Hm.
>
> Again, I'm open for discussion here. We might as well choose to not tie
> the ABI version to the libmultipath version at all, and simply start at
> 0.1 or whatevever for libmultipath. After all, looking up the ABI
> version in the commit history will be simple enough.
Since the ABI version isn't always going to match the release version, I
think it makes more sense to decouple them, so it's not sometimes
matching and sometimes not. We could go with a MAJOR.MINOR versioning
scheme, where we bump MINOR whenever we change the interface in a
backwards compatible way (like by adding a new symbol), and bump the
MAJOR and reset the MINOR whenever we change the interface in a
non-backwards compatible way (like by changing the parameters an
interface function takes, or removing a symbol). Although I'm not sure
we need to be so careful for libmultipath, since that library isn't for
external consumption.
-Ben
> Martin
>
next prev parent reply other threads:[~2020-09-25 22:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 13:36 [PATCH 00/11] multipath-tools: add linker version scripts mwilck
2020-09-24 13:36 ` [PATCH 01/11] libmultipath: find_mpe(): don't match with empty WWID mwilck
2020-09-24 13:36 ` [PATCH 02/11] libmultipath: copy mpp->hwe from pp->hwe mwilck
2020-09-24 20:12 ` Benjamin Marzinski
2020-09-25 16:01 ` Martin Wilck
2020-09-25 16:06 ` Benjamin Marzinski
2020-09-24 13:36 ` [PATCH 03/11] libmultipath: dm_map_present_by_uuid(): fix dm_task_create() call mwilck
2020-09-24 13:36 ` [PATCH 04/11] libdmmp tests: fix compilation mwilck
2020-09-24 13:36 ` [PATCH 05/11] libmultipath: prio: constify some function parameters mwilck
2020-09-24 13:36 ` [PATCH 06/11] libmultipath: checkers/prio: allow non-lazy .so loading mwilck
2020-09-24 20:27 ` Benjamin Marzinski
2020-09-24 13:36 ` [PATCH 07/11] multipath-tools Makefiles: separate rules for .so and man pages mwilck
2020-09-24 13:36 ` [PATCH 08/11] libmultipath: create separate .so for unit tests mwilck
2020-09-24 23:35 ` Benjamin Marzinski
2020-09-24 13:36 ` [PATCH 09/11] libmultipath: add linker version script mwilck
2020-09-24 13:36 ` [PATCH 10/11] libmpathpersist: " mwilck
2020-09-25 4:00 ` Benjamin Marzinski
2020-09-25 19:52 ` Martin Wilck
2020-09-25 22:10 ` Benjamin Marzinski [this message]
[not found] ` <20200925223207.GC3384@octiron.msp.redhat.com>
[not found] ` <c0a1e44fcc819583d972884aa126c486fc784fa9.camel@suse.com>
2020-09-25 23:22 ` Benjamin Marzinski
2020-09-24 13:36 ` [PATCH 11/11] libmpathcmd: " mwilck
2020-09-25 2:09 ` [PATCH 00/11] multipath-tools: add linker version scripts Benjamin Marzinski
2020-09-25 19:53 ` Martin Wilck
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=20200925221022.GB3384@octiron.msp.redhat.com \
--to=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=mwilck@suse.com \
/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;
as well as URLs for NNTP newsgroup(s).