/** \page rel_spec_112 Release Specific Information for HDF5 1.12
 *
 * Navigate back: \ref index "Main" / \ref release_specific_info
 * <hr>

\section sec_rel_spec_112_migrate Migrating from HDF5 1.10 to HDF5 1.12
Also see the video presentation:
<a href="https://www.hdfgroup.org/2020/03/moving-applications-from-1-10-to-hdf5-1-12-video-materials">Moving Applications from 1.10 to 1.12</a>

There were many existing functions that were modified in 1.12. Applications created with 1.10 or earlier
that use these functions will encounter errors when compiled with 1.12. This page describes how to
compile 1.10 and earlier applications with 1.12 without modifying an application, and provides details
on the functions that changed for users who wish to update their applications.

\li \ref subsec_rel_spec_112_migrate_compile
\li \ref subsec_rel_spec_112_migrate_func

For further information, see:
\li \ref sec_rel_spec_112_feat
\li \ref sec_rel_spec_112_change
\li \ref api-compat-macros

\subsection subsec_rel_spec_112_migrate_compile Compiling 1.10 and earlier applications with 1.12

Applications that were created with earlier HDF5 releases may not compile with 1.12 by default.
The \ref api-compat-macros allow users to work around this issue. Users can specify a
compatibility macro mapping for the version of HDF5 that an application was built with. For
example, a 1.10 application can be built with 1.12 using either an application or library mapping as follows:
\li To compile an application built with a version of HDF5 that includes deprecated symbols (the default),
    make sure to pass <code>-DH5_USE_110_API</code> to the compiler. For example:<br />
    <ul><li>Autotools: <code>h5cc -DH5_USE_110_API (C)</code></li>
    <li>CMake: <code>cmake -DCMAKE_C_FLAGS="-DH5_USE_110_API"</code> (and likewise for other <code>CMAKE_<LANG>_FLAGS</code>)</li></ul>
\li To build an HDF5 library with the 1.10 APIs specify:<br />
    <ul><li>Autotools: <code>\--with-default-api-version=v110</code><br />
    execute: <code>./configure \--with-default-api-version=v110</code></li>
    <li>CMake: <code>-DDEFAULT_API_VERSION:STRING=v110</code><br />
    If using the source code packaged with CMake configuration files (CMake-hdf5-1.12.0*), edit HDF5options.cmake, and add this line:<br />
    <code>set(ADD_BUILD_OPTIONS "${ADD_BUILD_OPTIONS} -DDEFAULT_API_VERSION:STRING=v110")</code></li></ul>

View the libhdf5.settings file to verify that the library was built with the 1.10 APIs:
\li <code>Default API mapping: v110</code> (under Features:)

\note However, users will not be able to take advantage of some of the new features in 1.12 if using these compatibility mappings.

\subsection subsec_rel_spec_112_migrate_func Functions that changed
Functions were modified in HDF5 version 1.12 to support a token type used in the
Virtual Object Layer (VOL) and to enable 64-bit selection encodings. These changes
are described below.

\remark
\li The updated versions of the functions have a number (for eg '2' or '3') at the end of the original function name.
\li The original versions of these functions were retained and renamed to have an earlier number (for eg '1')
at the end of the original function name.
\li A macro was created with the name of the original function.
\li Please read \ref api-compat-macros for more details on how the function names changed in version 1.12.

\subsection subsec_rel_spec_112_migrate_token Token Type
In HDF5 1.12, a token type, #H5O_token_t, replaced the address type, haddr_t, for representing locations
in an HDF5 file. This change better supports the Virtual Object Layer (VOL), as the concept of an "address"
does not make sense for many connectors. A token type is a more generic type that can function as both a
connector and address location.

This change affected the following functions:

| Original Function in 1.10/Macro in 1.12 (H5xxx) | Deprecated Function in 1.12 (H5xxx1) | New Function (using token type)<br>(H5xxx2 or H5xxx3 |
| ----------------------------------------------- | ------------------------------------ | ------------------------------- |
|                                                 |                                      |                                 |
| #H5Lget_info                                    | #H5Lget_info1                        | #H5Lget_info2                   |
| #H5Lget_info_by_idx                             | #H5Lget_info_by_idx1                 | #H5Lget_info_by_idx2            |
| #H5Literate                                     | #H5Literate1                         | #H5Literate2                    |
| #H5Literate_by_name                             | #H5Literate_by_name1                 | #H5Literate_by_name2            |
| #H5Lvisit                                       | #H5Lvisit1                           | #H5Lvisit2                      |
| #H5Lvisit_by_name                               | #H5Lvisit_by_name1                   | #H5Lvisit_by_name2              |
| #H5Oget_info                                    | #H5Oget_info1                        | #H5Oget_info3                   |
| #H5Oget_info_by_idx                             | #H5Oget_info_by_idx1                 | #H5Oget_info_by_idx3            |
| #H5Oget_info_by_name                            | #H5Oget_info_by_name1                | #H5Oget_info_by_name3           |
| #H5Ovisit                                       | #H5Ovisit1                           | #H5Ovisit3                      |
| #H5Ovisit_by_name                               | #H5Ovisit_by_name1                   | #H5Ovisit_by_name3              |
|                                                 |                                      |                                 |

\subsection subsec_rel_spec_112_migrate_encode Encoding Properties
These functions were introduced in HDF5 version 1.12 as part of the H5Sencode format change to enable
64-bit selection encodings and a dataspace selection that is tied to a file. See the \ref_sencode_fmt_change RFC for details.

| Original Function in 1.10/Macro in 1.12 (H5xxx) | Deprecated Function in 1.12 (H5xxx1) | New Function (using token type) |
| ----------------------------------------------- | ------------------------------------ | ------------------------------- |
|                                                 |                                      |                                 |
| #H5Pencode                                      | #H5Pencode1                          | #H5Pencode2                     |
| #H5Sencode                                      | #H5Sencode1                          | #H5Sencode2                     |
|                                                 |                                      |                                 |

\section sec_rel_spec_112_feat New Features in HDF5 Release 1.12
This release includes changes in the HDF5 storage format.
\note
PLEASE NOTE that HDF5-1.10 and earlier releases cannot read files created with the new features described below that are marked with a \*.

HDF5 1.12 introduces several new features in the HDF5 library:
\li \ref_sencode_fmt_change
\li \ref_rfc20180712
\li \ref_rfc20210219
\li \ref_rfc20140916
\li \ref subsec_rel_spec_112_feat_hyper

\subsection subsec_rel_spec_112_feat_vol Virtual Object Layer (VOL)
See the \ref_rfc20140916 for more information.

The Virtual Object Layer (VOL) is an abstraction layer within the HDF5 library that enables
different methods for accessing data and objects that conform to the HDF5 data model. The VOL
intercepts all HDF5 API calls that potentially modify data on disk and forwards those calls
to a plugin "object driver". The data on disk can be a different format than the HDF5 format.

The plugins can actually store the objects in variety of ways. A plugin could, for example, have
objects be distributed remotely over different platforms, provide a raw mapping of the model to
the file system, or even store the data in other file formats (like native netCDF or HDF4 format).
The user still gets the same data model where access is done to a single HDF5 \"container\";
however the plugin object driver translates from what the user sees to how the data is actually
stored. Having this abstraction layer maintains the object model of HDF5 and allows better usage of
new object storage file systems that are targeted for Exascale systems.

\subsection subsec_rel_spec_112_feat_hyper Hyperslab Performance Improvements
In 1.12.0 the hyperslab selection code was optimized to achieve better performance. In general,
performance improved by an order of a magnitude. In the case of reading a regular selection from
a 20 GB dataset into a one dimensional array, performance improved by a factor of 6000. If you
are interested in the benchmark we ran, please see issue HDFFV-10930 by logging into
jira.hdfgroup.org with your hdfgroup.org login.

\subsection subsec_rel_spec_112_feat_rfc Update to References (RFC) *
See the Update to References page for details on the changes in HDF5-1.12.

HDF5 references were extended to support attributes, as well as object and dataset selections
that reside in another HDF5 file. In order to support these features several functions were introduced:
\li Create (H5Rcreate*) functions were added for each reference type: object, dataset region and attribute.
\li A function was added to release a reference (H5Rdestroy). This is required because a region reference no longer modifies the original file.
\li Functions were added to query references (H5Rget*).
\li Other functions were added to simplify or clarify the API.

\subsection subsec_rel_spec_112_feat_sel Update to Selections
Several new H5S APIs were introduced to allow a user to more flexibly operate on two hyperslab selections.
See Update to Selections for more details.

<h4>RFCs</h4>
\li \ref_sencode_fmt_change
\li \ref_rfc20180712
\li \ref_rfc20210219
\li \ref_rfc20140916
\li \ref subsec_rel_spec_112_feat_hyper

\ref rel_spec_112_change
 *
 * <hr>
 * Navigate back: \ref index "Main" / \ref release_specific_info
 *
*/
