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 18:22:32 -0500
Message-ID: <20200925232232.GE3384@octiron.msp.redhat.com> (raw)
In-Reply-To: <c0a1e44fcc819583d972884aa126c486fc784fa9.camel@suse.com>

On Sat, Sep 26, 2020 at 01:07:34AM +0200, Martin Wilck wrote:
> On Fri, 2020-09-25 at 17:32 -0500, Benjamin Marzinski wrote:
> > On Fri, Sep 25, 2020 at 05:10:22PM -0500, Benjamin Marzinski wrote:
> > > 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).
> > 
> > Perhaps we might even want MAJOR.MINOR.RELEASE, where for upstream,
> > RELEASE is always 0. Distros can increment it if they need to
> > backport
> > changes, so that they don't conflict with existing upstream versions.
> 
> Sounds good. What MAJOR.MINOR version should we start with? 0.1 ? 1.0?

I realize that multipath-tools doesn't actually have a 1.0 release, but
1.0+ releases tradiontially mean that you believe that it's stable and
ready for use. Setting the libraries to 0.1 says to me that they aren't
meant for serious use, so I would vote for 1.0.

cc-ing dm-devel, because apparently I forgot to on my last email.

-Ben
 
> Martin
> 

  parent 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
     [not found]         ` <20200925223207.GC3384@octiron.msp.redhat.com>
     [not found]           ` <c0a1e44fcc819583d972884aa126c486fc784fa9.camel@suse.com>
2020-09-25 23:22             ` Benjamin Marzinski [this message]
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=20200925232232.GE3384@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