too much API breakage - mandatory use of semantic versioning #2
Description
HDF5 v1.12 has changed so much since the initial release of HDF5 that it's more appropriate to call it HDF6 at this stage.
The breaking API changes between minor HDF5 releases (eg. 1.8, 1.10, 1.12) are rather disconcerting. While there are various pre-processor tricks used as "workarounds", they are just brittle hacks in the end. Stuff like H5_USE_110_API is just papering over the unwarranted breakage.
The point of HDF is to be a boring abstraction for storage functionality, where by "boring" I mean stable. HDF5 is definitely not boring, which decreases its value and utility.
The use of semantic versioning to label HDF releases would help in this regard immensely. Minor releases such as v1.12 should not be introducing any kind of API breaks. Such breaks are much better communicated by bumping the major version number, for example HDF6, HDF7, etc.
The current approach of API breakage between minor releases is causing all sorts of issues. Examples:
- https://gitlab.com/conradsnicta/armadillo-code/-/issues/155
- latest versions of armadillo (9.850.1_1) and hdf5 (1.12.0) available from Homebrew do not interact together correctly, result in runtime error Homebrew/homebrew-core#52003
- Alternate Homebrew HDF5 fix mlpack/mlpack#2328
TLDR: I would suggest that the HDF5 developers be made explicitly aware that public API breaks in HDF5 releases are not exactly conducive to productivity. It would be useful to properly communicate such changes via an increase in the major version number, for example HDF6. The current practice of updating "HDF5" with incompatible changes is overall a negative net contribution.