DM-Devel Archive on lore.kernel.org
 help / color / Atom feed
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
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
> 

  reply index

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

DM-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dm-devel/0 dm-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dm-devel dm-devel/ https://lore.kernel.org/dm-devel \
		dm-devel@redhat.com
	public-inbox-index dm-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.redhat.dm-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git