public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Drung <benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: rdma-core package version schema
Date: Thu, 05 Jan 2017 20:01:07 +0100	[thread overview]
Message-ID: <1483642867.5227.18.camel@profitbricks.com> (raw)

Hi,

I looked at the Debian packaging of rdma-core and stumbled over the
versioning. You change the version of the binary library packages
(libibcm1, libibumad3, etc.) from the Debian package version (currently
12-1) to their shared library versions. This change is uncommon and
confusing besides other issues. [1] It is common that the package
version differ from the library (soname) version. As potential Debian
sponsor I would reject this package version change.

The second problematic thing is that each library has its own major and
minor number, but use the package version as patch level. This
restricts the package version to one number which will increase fast.

>From my Debian maintainer perspective, I recommend following change:
Maintain two different versions, the package version and the library
versions.

The package version could follow the semantic versioning [2], the
version schema from the kernel [3], or by date [4]. Make that version
number be useful in itself. I suggest to start with version 2.0 (since
1.3.10 is the highest version that I found in one of its libraries when
they were maintained separately).

For the library version numbers, you could either maintain them
separately (increase only if you touch that library between two
releases) or maintain a common patch level (like you do now).

PS: I am thinking about offering becoming a co-maintainer for the rdma-
core Debian package.

[1] Andrey Rahmatullin wrote in https://bugs.debian.org/850145 :
"Please make sure you fully understand the consequences of using binary
package versions different from the source one."
[2] http://semver.org/
[3] major.minor.patch were major is increased when minor becomes too
big.
[4] year.${number of release of the year}.patch (e.g. 2017.1)

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.drung-EIkl63zCoXaH+58JC4qpiA@public.gmane.org
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2017-01-05 19:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05 19:01 Benjamin Drung [this message]
     [not found] ` <1483642867.5227.18.camel-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2017-01-05 23:09   ` rdma-core package version schema Jason Gunthorpe
     [not found]     ` <20170105230928.GA4262-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-06 17:28       ` Benjamin Drung
     [not found]         ` <1483723704.5227.23.camel-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2017-01-06 18:47           ` Jason Gunthorpe
     [not found]             ` <20170106184717.GC5724-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-08  8:51               ` Leon Romanovsky
2017-01-08  8:47           ` Leon Romanovsky
     [not found]             ` <20170108084759.GJ15685-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-01-11 12:59               ` Knut Omang
     [not found]                 ` <1484139556.2191.48.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-01-11 14:47                   ` Leon Romanovsky
2017-01-11 22:10                   ` Jason Gunthorpe
     [not found]                     ` <20170111221004.GA31081-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-11 22:17                       ` Knut Omang

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=1483642867.5227.18.camel@profitbricks.com \
    --to=benjamin.drung-eikl63zcoxah+58jc4qpia@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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