To my surprise, I recently discovered that contrary to popular software development conventions, the releases of the same “minor” version of HDF5 but different “patch” version are not binary compatible with each other.
This causes major grievances for packagers like Linux distributions. For example, the HDF5 version of CentOS - a Linux distribution that’s popular with many scientists - will forever[1] stick with HDF5 version 1.8.12, which is 5 years old at the time of writing.
The reason is that a bump in the version would require a rebuild of all the dependent packages in the EPEL repository.
When redistributing HDF5 along with a binary application, this also effectively locks the application out of all bugfixes and security fixes that may have been released after the original version.
In June 2016 (now 2.5 years ago) @epourmal has acknowledged[2] that the issue is of “high priority” and that they "will get back to it after all features planned for 1.10.0 are finally out ". Are there any updates regarding binary compatibility?
After checking out the ABI stability tracker for HDF5 [3] that was created by another user of this forum [4], it seems that the ABI has mostly stabilized. Are there official statements, or statements in the documentation about the ABI compatibility between versions?
In HDF5 1.10.4 we made a mistake with H5Oget_info* and introduced new binary compatibility issues. We didn’t acknowledged the mistake on FORUM, so I am doing it now and apologize for our slow response.
We will revert the H5Oget_info* changes in 1_10 branch and in the upcoming 1.10.5 release.
It is very unfortunate that the mistake was reported after the 1.10.4 release.
The community and especially package and software stacks maintainers, could help us by testing the release candidates. We post on FORUM when a release candidate is available and your timely feedback is highly appreciated. When we don’t hear from you, we assume that everything is working.
We discussed [2] internally, but the issue for maintenance releases is still not resolved. Any volunteers to work on it with us?
It is very unfortunate that the mistake was reported after the 1.10.4
release.
The community and especially package and software stacks maintainers,
could help us by testing the release candidates. We post on FORUM when a
release candidate is available and your timely feedback is highly
appreciated. When we don’t hear from you, we assume that everything is
working.
I am sorry that the problem was reported with a large time lag; in the
future I will try to pay more attention to RC announcements.
At the same time, this particular issue was reliably caught by robots.
Might it be possible that ABI stability checks are integrated into
release testing procedure, or even continuous integration system?
