Add application mapping option for current version

[Dave-Allured]

Is your feature request related to a problem? Please describe.

Application mapping options that match the current major HDF5 version are missing. This causes extra maintenance for application code when the major version is incremented, or when multiple applications are supported. For reference, see the "Application Mapping Options" section on this page:

https://portal.hdfgroup.org/display/HDF5/API+Compatibility+Macros

Describe the solution you'd like

• Add a definition for -DH5_USE_114_API to code and documentation for the next release of HDF5 1.14.
• Likewise, add -DH5_USE_112_API for the next release of 1.12, -DH5_USE_110_API for the next release of 1.10, and -DH5_USE_18_API for the next release of 1.8.

Describe alternatives you've considered

• The status quo is manageable but chaotic.
• Use of the detailed function mapping options is time-consuming and contrary to the general intention of the HDF5 compatibility features.

Additional context

The general context is the need to recompile many existing applications against HDF5 updates from time to time. Currently, the only simple way for an application to build against the current API version is to build the HDF5 library with the default API. The app does not have a simple way to signal this version dependency. The desired current-version mapping option does not yet exist. The app just assumes and uses the current default API version.

Now when a major HDF5 update comes along, apps with version dependencies will not compile without manual intervention to add the newly available down-level application mapping option. This is difficult for software repositories and IT managers that maintain builds for possibly hundreds of HDF5-dependent applications.

Apps that are already signaling with a down-level mapping option, e.g. -DH5_USE_110_API, do not have this problem, because they are "already fixed".

This proposal would make it simple to proactively add the appropriate application mapping option, e.g. -DH5_USE_114_API, when the app is first deployed. This is the moment when the app developer or installer is most familiar with the new code and its API dependency. If this could be done routinely with guaranteed option strings, then trouble at a later HDF5 update would be reduced.

There is a second purpose. Some users will build the HDF5 library with a down-level default API, e.g. --with-default-api-version=v110, then share this build with multiple applications. Without a mapping option for the latest API, there is no simple way for the user to build an application against this latest API. This current-version mapping option is simply missing from the available set of options. An example scenario is https://trac.macports.org/ticket/67636 . A current-version application mapping option would solve this problem.

[byrnHDF]

H5version.h file is created by the make_vers PERL script. This is the first file that will need to be adjusted.

[Dave-Allured]

I have reconsidered my request. I only need some sort of guarantee that proactive -DH5_USE_114_API will be compatible with current and future HDF5 releases, and likewise for future major versions. It can be a no-op with 1.14 versions.

I do not see a real need for functionality with a down-level default API, contrary to what I said in the last paragraph above. This should save some development effort.