Re: RFS: libibverbs, libmthca - InfiniBand libraries
Hi Roland,
Am Donnerstag, den 15.09.2005, 17:17 -0700 schrieb Roland Dreier:
> > + SONAME libibverbs.so.1
> > is a very challenging goal. Are you sure that all 1.x.y releases will
> > ship the same API for each and every upcoming version of x and y? Not
> > that this is impossible to reach, just mentioning the implications.
>
> I'm not sure what you mean here. The SONAME doesn't have anything to
> do with the naming of releases, does it? I am just planning on
> bumping the SONAME to .2 if there is an incompatible change.
as Neil already pointed out, each SONAME should have a unique binary
package name. Thus if you put only lib*.so.1 as SONAME you'll have to
increment this to quite a lot if your API needs to change often. Usually
it's preferred to use lib*.so.1.0 as SONAME so you have the major *and*
minor to tweak your API and document (r)evolutionary steps with
adjusting the more suitable one of the two. As said, your approach isn't
flawed or wrong, I was just making sure you recall the implications for
packaging and shipping correctly.
Am Donnerstag, den 15.09.2005, 17:21 -0700 schrieb Roland Dreier:
> > well, from the URL you mention in the copyright file, the following
> > changes were apparently commited to SVN after your -rc2 snapshot btw.:
>
> > Files libibverbs/examples/devinfo.c and libibverbs-1.0-rc2/examples/devinfo.c differ
> > Files libibverbs/include/infiniband/opcode.h and libibverbs-1.0-rc2/include/infiniband/opcode.h differ
> > Files libibverbs/libibverbs.spec.in and libibverbs-1.0-rc2/libibverbs.spec.in differ
> > Files libibverbs/src/memory.c and libibverbs-1.0-rc2/src/memory.c differ
>
> > Files libmthca/libmthca.spec.in and libmthca-1.0-rc2/libmthca.spec.in differ
> > Files libmthca/src/qp.c and libmthca-1.0-rc2/src/qp.c differ
> > Files libmthca/src/srq.c and libmthca-1.0-rc2/src/srq.c differ
> > Files libmthca/src/verbs.c and libmthca-1.0-rc2/src/verbs.c differ
>
> Some of these changes seem bogus. For example, I don't think opcode.h
> has changed in a long time.
well, as you named the .../trunk URL as the place where you "downloaded
the source", it's virtually impossible to verify the orig.tar.gz. Even
if you name a certain revision within SVN it's quite more problematic to
get the proper export as just plain download some *.tar.gz from the
release site. And if you tell these are bogus, it's even worse, as
technically your sponsor or ftpmasters could reject the upload due to
unneccessarily altered original tarball.
> > As you can clearly see, the preference towards a real "release" is
> > increasing. ;)
>
> Fair enough, although I'm not sure how much of a difference calling
> something 1.0.0 versus 1.0-rc2 makes. Development will continue and
> there will be upstream changes no matter what gets packaged.
yes, no problem with that, but at least everybody knows what the
"reference" for the packaging was and is. It just makes it more
transparent for developers to have an immobile target to aim at. =)
--
Best regards,
Kilian
Reply to: