ABI stability?

[hmaarrfk]

At conda forge we package the HDF5 assuming that there might be ABI breaks between patch versions of the HDF5 library.

I would like some longer term stability, just between minor version.

Is this currently the case? It would reduce the number of rebuilds we need on new version

Xred conda-forge/hdf5-feedstock#202

[derobins]

HDF5 does not conform to semantic versioning norms. Well, we do, but with the numbers shifted.

Normal library: major.minor.patch
HDF5: 1.major.minor-patch

We do check for binary compatibility between releases to ensure minor releases don't break the ABI. We (unfortunately) export the config.h file so we sometimes have symbols change there, but the real HDF5 ABI should be stable.

For example, the current latest major release of the library is 1.14.x, and it's latest minor release is 1.14.1. When 1.14.2 comes out, we'll check for ABI compatibility with 1.14.1. HDF5 1.16.0 (or 2.0.0, see below) could break the ABI (though we have compatibility mechanisms to make things easier for people). We have never incremented the first number in the HDF5 version. It's always been 1.

The exported config.h file (renamed H5pubconf.h, with symbols decorated with H5_) will stop being exported in the (hopefully near) future, to be replaced with a template header file (H5features.h) that only includes the "feature on/off" symbols users need to know about.

The next major release of HDF5 should be HDF5 2.0.0, which will conform to semantic versioning going forward. I can't change the old scheme in existing releases without driving everyone nuts, though, and we do need to add new API calls to the library, so I can't just freeze the API at, say, 1.14.1.

Is there anything else you need to know about HDF5's versions? Are there other things we can do to make packing HDF5 easier?

[hmaarrfk]

Thank you for the detailed explanation!

No further questions.

Best,

Mark