[openib-general] [ANNOUNCE] libibverbs 1.0-rc5 released

[Roland Dreier]

I just tagged a 1.0-rc5 release of libibverbs and pushed it out to the
relevant channels, which means that it should appear on http://openib.org/downloads/
shortly.  Once the Fedora project build system is fixed, I will also
kick off builds for Fedora Extras, so binary packages for Fedora 4 and
5 will appear on standard Fedora mirrors in a few days

Changes since 1.0-rc4 include:

 - Change from dlist-based ibv_get_devices() API to simpler
   array-based ibv_get_device_list() API.  This breaks source
   compatibility with 1.0-rc4.
 - Add Sean Hefty's user/kernel marshalling functions.
 - Lots of fixes for pingpong examples.

See the ChangeLog in the package for full details.

I think we're getting close to a full 1.0 release with a frozen API
and ABI.  My plans for getting there are the following:

 - As of now, the only changes to the API that I will accept are pure
   additions that do not break source compatibility with existing
   consumer or provider code.  Any exceptions to this will have to be
   extremely well justified.

 - In about 3-4 weeks, I'll release 1.0-rc6.  This release will add
   support for resizing CQs and (if the code appears in time) query QP
   and query SRQ support from Dotan Barak at Mellanox.

 - Once 1.0-rc6 is out, I'll consider the API and ABI absolutely
   frozen.  In other words, any binary applications or device provider
   libraries built against 1.0-rc6 will continue to work aganst any
   later release in the 1.0 series.  This means that any changes that
   affect source or binary compatibility with existing consumer or
   provider code will have to have end-of-the-world type consequences
   for me to accept them.

 - Bug fixes are of course always welcome at any point in the
   development cycle.

 - Depending on how testing feedback looks, 3-4 weeks after 1.0-rc6,
   I'll release either a full 1.0, or if we're unlucky, 1.0-rc7.

 - Once 1.0 is out, I'll continue to accept changes that don't affect
   compatibility, and continue to do 1.0.1, 1.0.2, etc. releases as
   necessary.

 - When API or ABI breaking changes become necessary, I'll kick off a
   1.1 release series and we can go nuts again.