mirror of
https://github.com/HDFGroup/hdf5.git
synced 2025-02-23 16:20:57 +08:00
Update release_docs HISTORY scheme (#2443)
We will no longer maintain HISTORY files for other maintenance branches, so those have been removed. Adds a README.md explaining the purpose and procedures of HDF5 HISTORY. Also adds a newsletter template and updates the RELEASE.txt note part of CONTRIBUTING.md. Also cleans out RELEASE.txt post-HDF5-1.14.0
This commit is contained in:
parent
b5ddec4554
commit
768575225e
@ -86,36 +86,7 @@ application developers, library developers, and system administrators.
|
|||||||
|
|
||||||
# Release Note <A NAME="releasenote"></A>
|
# Release Note <A NAME="releasenote"></A>
|
||||||
|
|
||||||
* **Entry Syntax**
|
The use and format of release notes is described in `doc/release_txt_notes.md` in this source code tree
|
||||||
The release note entry syntax is shown below.
|
|
||||||
|
|
||||||
```
|
|
||||||
- Title/Problem
|
|
||||||
|
|
||||||
Problem/Solution
|
|
||||||
|
|
||||||
Signature
|
|
||||||
```
|
|
||||||
|
|
||||||
* **Entry Elements** - The elements of the entry - title, problem, solution, and signature - are described in more detail in the table
|
|
||||||
below. Descriptions of the problem and the solution should be clear without any ambiguities and should be short without losing clarity or specifics.
|
|
||||||
|
|
||||||
* **Title** - The title or tag should identify one or more categories that will help readers decide if the entry is something they need to study. Can be combined with the `Problem` element
|
|
||||||
* **Problem** - Describe the problem and how users might see the problem in a paragraph.
|
|
||||||
You might also consider the following as you describe the problem:
|
|
||||||
* Under what specific conditions does this issue arise?
|
|
||||||
* Under what specific conditions are we sure this issue will not arise?
|
|
||||||
* For a performance issue, instead of saying something is a performance issue, describe what the performance impact of issue is?
|
|
||||||
* **Solution** - Describe the solution in another paragraph.
|
|
||||||
You might also consider the following as you describe the solution:
|
|
||||||
* What was done to resolve the issue?
|
|
||||||
* What is the functional impact?
|
|
||||||
* Is there a workaround – a way for users design their software so as not to encounter the issue? If so, what is the workaround?
|
|
||||||
* For a performance fix, how has the performance improved? Links to published documentation would be good.
|
|
||||||
* **Signature** - Each entry must be signed with the initials of the author, the date in YYYY/MM/DD format, and the JIRA ticket number. The
|
|
||||||
following is an example entry written by developer Xavier Zolo on April 16, 2014 about JIRA ticket HDFFV-5555: (XYZ - 2014/04/16, HDFFV-5555). The
|
|
||||||
signature is enclosed in parentheses. JIRA or Github numbers should not be used in the description of the problem or the solution. They are like
|
|
||||||
abbreviations that customers and external users will not be able to interpret.
|
|
||||||
|
|
||||||
# Checklist <A NAME="checklist"></A>
|
# Checklist <A NAME="checklist"></A>
|
||||||
|
|
||||||
|
107
doc/release_txt_notes.md
Normal file
107
doc/release_txt_notes.md
Normal file
@ -0,0 +1,107 @@
|
|||||||
|
# Writing Notes in a RELEASE.txt File
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
We have been challenged to write more helpful entries in our RELEASE.txt file
|
||||||
|
for new features, improvements, and bug fixes. To help users determine the
|
||||||
|
effects of our software changes on their applications, we have developed a
|
||||||
|
template that can be used to write release notes. The template is described on
|
||||||
|
the rest of this page.
|
||||||
|
|
||||||
|
Some of our users face scrutiny from regulatory agencies for their use of
|
||||||
|
software they did not develop (aka SOUP). When they use our software, they have
|
||||||
|
to be aware of every change we make. For every change we make, they need to
|
||||||
|
investigate the effect the change will have on their software. If our change
|
||||||
|
affects their application, they may have to have their software retested or
|
||||||
|
re-certified.
|
||||||
|
|
||||||
|
[SOUP](https://en.wikipedia.org/wiki/Software_of_unknown_pedigree) stands for Software Of Unknown/Uncertain Pedigree/Provenance
|
||||||
|
|
||||||
|
|
||||||
|
## When to write a RELEASE.txt note
|
||||||
|
|
||||||
|
Generally, a release note must be written for every change that is made to the
|
||||||
|
code for which users might see a change in the way the software works. In other
|
||||||
|
words, if a user might see a difference in the way the software works, a note
|
||||||
|
should be written. By code we mean the text that will be compiled into one of
|
||||||
|
the company's software products. The code includes configuration changes and
|
||||||
|
changes to tools users might work with to configure and build our software.
|
||||||
|
|
||||||
|
A release note does not need to be written for changes to the code that users
|
||||||
|
will not see.
|
||||||
|
|
||||||
|
These things DO require a release note:
|
||||||
|
|
||||||
|
* New features
|
||||||
|
* Changes in functionality/semantics
|
||||||
|
* Anything that changes functionality or symbols in a public header file
|
||||||
|
* Command-line tool option changes
|
||||||
|
* Adding or dropping support for compilers or operating systems
|
||||||
|
* Build system (Autotools, CMake) changes that users will encounter
|
||||||
|
|
||||||
|
These things do NOT require a release note:
|
||||||
|
|
||||||
|
* Internal comments
|
||||||
|
* Refactoring that does not change behavior or public headers (`H5XYpublic.h`)
|
||||||
|
* Minor build system changes (adding warning flags)
|
||||||
|
|
||||||
|
Notes should also be added for known problems. Known problems are issues that
|
||||||
|
we know about and have not yet been able to fix.
|
||||||
|
|
||||||
|
## RELEASE.txt entry format
|
||||||
|
|
||||||
|
```
|
||||||
|
- Title
|
||||||
|
|
||||||
|
Problem
|
||||||
|
|
||||||
|
Solution
|
||||||
|
|
||||||
|
Signature
|
||||||
|
```
|
||||||
|
|
||||||
|
## RELEASE.txt entry elements
|
||||||
|
|
||||||
|
### Title
|
||||||
|
|
||||||
|
The title or tag should identify one or more categories that will help readers
|
||||||
|
decide if the entry is something they need to study. Categories include problem
|
||||||
|
areas, tool names, and code file names. Two examples are "Memory Leak" and
|
||||||
|
"h5repack". A code file such as H5R.c or H5Z.c can be used as the title if the
|
||||||
|
problem is located in the code file. If both a title and one or more tags are
|
||||||
|
used, separate each with a period. For example, "Changed Autotools Build Behavior. Fortran."
|
||||||
|
adds the Fortran tag to the title Changed Autotools Build Behavior. Use
|
||||||
|
standard capitalization rules.
|
||||||
|
|
||||||
|
### Problem
|
||||||
|
|
||||||
|
Describe the problem and how users might see the problem in a paragraph.
|
||||||
|
|
||||||
|
You might also consider the following as you describe the problem:
|
||||||
|
|
||||||
|
* Under what specific conditions does this issue arise?
|
||||||
|
* Under what specific conditions are we sure this issue will not arise?
|
||||||
|
* For a performance issue, instead of saying something is a performance issue, describe what the performance impact of issue is?
|
||||||
|
|
||||||
|
### Solution
|
||||||
|
|
||||||
|
Describe the solution in another paragraph.
|
||||||
|
|
||||||
|
You might also consider the following as you describe the solution:
|
||||||
|
|
||||||
|
* What was done to resolve the issue?
|
||||||
|
* What is the functional impact?
|
||||||
|
* Is there a workaround – a way for users design their software so as not to encounter the issue? If so, what is the workaround?
|
||||||
|
* For a performance fix, how has the performance improved? Links to published documentation would be good.
|
||||||
|
|
||||||
|
### Signature
|
||||||
|
|
||||||
|
Each entry must be signed with the initials of the author, the date in
|
||||||
|
YYYY/MM/DD format, and the JIRA ticket number. The signature is enclosed in
|
||||||
|
parentheses.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
```
|
||||||
|
(ABC - 2023/02/28, JIRA-12345, GitHub #1234)
|
||||||
|
```
|
File diff suppressed because it is too large
Load Diff
@ -1,628 +0,0 @@
|
|||||||
HDF5 History
|
|
||||||
============
|
|
||||||
|
|
||||||
This file contains development history of the HDF5 1.12 branch
|
|
||||||
|
|
||||||
01. Release Information for hdf5-1.12.0
|
|
||||||
|
|
||||||
[Search on the string '%%%%' for section breaks of each release.]
|
|
||||||
|
|
||||||
%%%%1.12.0%%%%
|
|
||||||
|
|
||||||
HDF5 version 1.12.0 released on 2020-02-28
|
|
||||||
================================================================================
|
|
||||||
|
|
||||||
|
|
||||||
INTRODUCTION
|
|
||||||
|
|
||||||
This document describes the new features introduced in the HDF5 1.12.0 release.
|
|
||||||
It contains information on the platforms tested and known problems in this
|
|
||||||
release. For more details check the HISTORY*.txt files in the HDF5 source.
|
|
||||||
|
|
||||||
Note that documentation in the links below will be updated at the time of the
|
|
||||||
release.
|
|
||||||
|
|
||||||
Links to HDF5 documentation can be found on The HDF5 web page:
|
|
||||||
|
|
||||||
https://portal.hdfgroup.org/display/HDF5/HDF5
|
|
||||||
|
|
||||||
The official HDF5 releases can be obtained from:
|
|
||||||
|
|
||||||
https://www.hdfgroup.org/downloads/hdf5/
|
|
||||||
|
|
||||||
More information about the new features can be found at:
|
|
||||||
|
|
||||||
https://portal.hdfgroup.org/display/HDF5/New+Features+in+HDF5+Release+1.12
|
|
||||||
|
|
||||||
If you have any questions or comments, please send them to the HDF Help Desk:
|
|
||||||
|
|
||||||
help@hdfgroup.org
|
|
||||||
|
|
||||||
|
|
||||||
CONTENTS
|
|
||||||
|
|
||||||
- New Features
|
|
||||||
- Support for new platforms and languages
|
|
||||||
- Bug Fixes since HDF5-1.12.0-alpha1
|
|
||||||
- Major Bug Fixes since HDF5-1.10.0
|
|
||||||
- Supported Platforms
|
|
||||||
- Tested Configuration Features Summary
|
|
||||||
- More Tested Platforms
|
|
||||||
- Known Problems
|
|
||||||
- CMake vs. Autotools installations
|
|
||||||
|
|
||||||
|
|
||||||
New Features
|
|
||||||
============
|
|
||||||
|
|
||||||
Configuration:
|
|
||||||
-------------
|
|
||||||
- Added test script for file size compare
|
|
||||||
|
|
||||||
If CMake minimum version is at least 3.14, the fileCompareTest.cmake
|
|
||||||
script will compare file sizes.
|
|
||||||
|
|
||||||
(ADB - 2020/02/24, HDFFV-11036)
|
|
||||||
|
|
||||||
- Update CMake minimum version to 3.12
|
|
||||||
|
|
||||||
Updated CMake minimum version to 3.12 and added version checks
|
|
||||||
for Windows features.
|
|
||||||
|
|
||||||
(ADB - 2020/02/05, TRILABS-142)
|
|
||||||
|
|
||||||
- Fixed CMake include properties for Fortran libraries
|
|
||||||
|
|
||||||
Corrected the library properties for Fortran to use the
|
|
||||||
correct path for the Fortran module files.
|
|
||||||
|
|
||||||
(ADB - 2020/02/04, HDFFV-11012)
|
|
||||||
|
|
||||||
- Added common warnings files for gnu and intel
|
|
||||||
|
|
||||||
Added warnings files to use one common set of flags
|
|
||||||
during configure for both autotools and CMake build
|
|
||||||
systems. The initial implementation only affects a
|
|
||||||
general set of flags for gnu and intel compilers.
|
|
||||||
|
|
||||||
(ADB - 2020/01/17)
|
|
||||||
|
|
||||||
- Added new options to CMake for control of testing
|
|
||||||
|
|
||||||
Added CMake options (default ON);
|
|
||||||
HDF5_TEST_SERIAL AND/OR HDF5_TEST_PARALLEL
|
|
||||||
combined with:
|
|
||||||
HDF5_TEST_TOOLS
|
|
||||||
HDF5_TEST_EXAMPLES
|
|
||||||
HDF5_TEST_SWMR
|
|
||||||
HDF5_TEST_FORTRAN
|
|
||||||
HDF5_TEST_CPP
|
|
||||||
HDF5_TEST_JAVA
|
|
||||||
|
|
||||||
(ADB - 2020/01/15, HDFFV-11001)
|
|
||||||
|
|
||||||
- Added Clang sanitizers to CMake for analyzer support if compiler is clang.
|
|
||||||
|
|
||||||
Added CMake code and files to execute the Clang sanitizers if
|
|
||||||
HDF5_ENABLE_SANITIZERS is enabled and the USE_SANITIZER option
|
|
||||||
is set to one of the following:
|
|
||||||
Address
|
|
||||||
Memory
|
|
||||||
MemoryWithOrigins
|
|
||||||
Undefined
|
|
||||||
Thread
|
|
||||||
Leak
|
|
||||||
'Address;Undefined'
|
|
||||||
|
|
||||||
(ADB - 2019/12/12, TRILAB-135)
|
|
||||||
|
|
||||||
- Update CMake for VS2019 support
|
|
||||||
|
|
||||||
CMake added support for VS2019 in version 3.15. Changes to the CMake
|
|
||||||
generator setting required changes to scripts. Also updated version
|
|
||||||
references in CMake files as necessary.
|
|
||||||
|
|
||||||
(ADB - 2019/11/18, HDFFV-10962)
|
|
||||||
|
|
||||||
|
|
||||||
Library:
|
|
||||||
--------
|
|
||||||
- Refactored public exposure of haddr_t type in favor of "object tokens"
|
|
||||||
|
|
||||||
To better accommodate HDF5 VOL connectors where "object addresses in a file"
|
|
||||||
may not make much sense, the following changes were made to the library:
|
|
||||||
|
|
||||||
* Introduced new H5O_token_t "object token" type, which represents a
|
|
||||||
unique and permanent identifier for referencing an HDF5 object within
|
|
||||||
a container; these "object tokens" are meant to replace object addresses.
|
|
||||||
Along with the new type, a new H5Oopen_by_token API call was introduced
|
|
||||||
to open an object by a token, similar to how object addresses were
|
|
||||||
previously used with H5Oopen_by_addr.
|
|
||||||
|
|
||||||
* Introduced new H5Lget_info2, H5Lget_info_by_idx2, H5Literate2, H5Literate_by_name2,
|
|
||||||
H5Lvisit2 and H5Lvisit_by_name2 API calls, along with their associated H5L_info2_t
|
|
||||||
struct and H5L_iterate2_t callback function, which work with the newly-introduced
|
|
||||||
object tokens, instead of object addresses. The original functions have been
|
|
||||||
renamed to version 1 functions and are deprecated in favor of the new version 2
|
|
||||||
functions. The H5L_info_t and H5L_iterate_t types have been renamed to version 1
|
|
||||||
types and are now deprecated in favor of their version 2 counterparts. For each of
|
|
||||||
the functions and types, compatibility macros take place of the original symbols.
|
|
||||||
|
|
||||||
* Introduced new H5Oget_info3, H5Oget_info_by_name3, H5Oget_info_by_idx3,
|
|
||||||
H5Ovisit3 and H5Ovisit_by_name3 API calls, along with their associated H5O_info2_t
|
|
||||||
struct and H5O_iterate2_t callback function, which work with the newly-introduced
|
|
||||||
object tokens, instead of object addresses. The version 2 functions are now
|
|
||||||
deprecated in favor of the version 3 functions. The H5O_info_t and H5O_iterate_t
|
|
||||||
types have been renamed to version 1 types and are now deprecated in favor of their
|
|
||||||
version 2 counterparts. For each, compatibility macros take place of the original
|
|
||||||
symbols.
|
|
||||||
|
|
||||||
* Introduced new H5Oget_native_info, H5Oget_native_info_by_name and
|
|
||||||
H5Oget_native_info_by_idx API calls, along with their associated H5O_native_info_t
|
|
||||||
struct, which are used to retrieve the native HDF5 file format-specific information
|
|
||||||
about an object. This information (such as object header info and B-tree/heap info)
|
|
||||||
has been removed from the new H5O_info2_t struct so that the more generic
|
|
||||||
H5Oget_info(_by_name/_by_idx)3 routines will not try to retrieve it for non-native
|
|
||||||
VOL connectors.
|
|
||||||
|
|
||||||
* Added new H5Otoken_cmp, H5Otoken_to_str and H5Otoken_from_str routines to compare
|
|
||||||
two object tokens, convert an object token into a nicely-readable string format and
|
|
||||||
to convert an object token string back into a real object token, respectively.
|
|
||||||
|
|
||||||
(DER, QAK, JTH - 2020/01/16)
|
|
||||||
|
|
||||||
- Virtual Object Layer (VOL)
|
|
||||||
|
|
||||||
In this major HDF5 release we introduce HDF5 Virtual Object Layer (VOL).
|
|
||||||
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 layer 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. For more information
|
|
||||||
about VOL we refer the reader to the following documents (under review):
|
|
||||||
|
|
||||||
VOL HDF5 APIs
|
|
||||||
https://portal.hdfgroup.org/display/HDF5/Virtual+Object++Layer
|
|
||||||
|
|
||||||
VOL Documentation
|
|
||||||
https://bitbucket.hdfgroup.org/projects/HDFFV/repos/hdf5doc/browse/RFCs/HDF5/VOL
|
|
||||||
|
|
||||||
Repository with VOL plugins
|
|
||||||
https://bitbucket.hdfgroup.org/projects/HDF5VOL
|
|
||||||
|
|
||||||
- Enhancements to HDF5 References
|
|
||||||
|
|
||||||
HDF5 references were extended to support attributes, and object and dataset
|
|
||||||
selections that reside in another HDF5 file. For more information including
|
|
||||||
a list of new APIs, see
|
|
||||||
|
|
||||||
https://portal.hdfgroup.org/display/HDF5/Update+to+References
|
|
||||||
|
|
||||||
- Add new public function H5Sselect_adjust.
|
|
||||||
|
|
||||||
This function shifts a dataspace selection by a specified logical offset
|
|
||||||
within the dataspace extent. This can be useful for VOL developers to
|
|
||||||
implement chunked datasets.
|
|
||||||
|
|
||||||
(NAF - 2019/11/18)
|
|
||||||
|
|
||||||
- Add new public function H5Sselect_project_intersection.
|
|
||||||
|
|
||||||
This function computes the intersection between two dataspace selections
|
|
||||||
and projects that intersection into a third selection. This can be useful
|
|
||||||
for VOL developers to implement chunked or virtual datasets.
|
|
||||||
|
|
||||||
(NAF - 2019/11/13, ID-148)
|
|
||||||
|
|
||||||
- Add new public function H5VLget_file_type.
|
|
||||||
|
|
||||||
This function returns a datatype equivalent to the supplied datatype but
|
|
||||||
with the location set to be in the file. This datatype can then be used
|
|
||||||
with H5Tconvert to convert data between file and in-memory representation.
|
|
||||||
This funcition is intended for use only by VOL connector developers.
|
|
||||||
|
|
||||||
(NAF - 2019/11/08, ID-127)
|
|
||||||
|
|
||||||
- New S3 and HDFS Virtual File Drivers (VFDs)
|
|
||||||
|
|
||||||
This release has two new VFDs. The S3 VFD allows accessing HDF5 files on
|
|
||||||
AWS S3 buckets. HDFS VFD allows accessing HDF5 files stored on Apache HDFS.
|
|
||||||
See https://portal.hdfgroup.org/display/HDF5/Virtual+File+Drivers+-+S3+and+HDFS
|
|
||||||
for information on enabling those drivers and using those APIs.
|
|
||||||
|
|
||||||
Below are specific instructions for enabling S3 VFD on Windows:
|
|
||||||
|
|
||||||
Fix windows requirements and java tests. Windows requires CMake 3.13.
|
|
||||||
- Install openssl library (with dev files);
|
|
||||||
from "Shining Light Productions". msi package preferred.
|
|
||||||
- PATH should have been updated with the installation dir.
|
|
||||||
- set ENV variable OPENSSL_ROOT_DIR to the installation dir.
|
|
||||||
- set ENV variable OPENSSL_CONF to the cfg file, likely %OPENSSL_ROOT_DIR%\bin\openssl.cfg
|
|
||||||
- Install libcurl library (with dev files);
|
|
||||||
- download the latest released version using git: https://github.com/curl/curl.git
|
|
||||||
- Open a Visual Studio Command prompt
|
|
||||||
- change to the libcurl root folder
|
|
||||||
- run the "buildconf.bat" batch file
|
|
||||||
- change to the winbuild directory
|
|
||||||
- nmake /f Makefile.vc mode=dll MACHINE=x64
|
|
||||||
- copy libcurl-vc-x64-release-dll-ipv6-sspi-winssl dir to C:\curl (installation dir)
|
|
||||||
- set ENV variable CURL_ROOT to C:\curl (installation dir)
|
|
||||||
- update PATH ENV variable to %CURL_ROOT%\bin (installation bin dir).
|
|
||||||
- the aws credentials file should be in %USERPROFILE%\.aws folder
|
|
||||||
- set the ENV variable HDF5_ROS3_TEST_BUCKET_URL to the s3 url for the
|
|
||||||
s3 bucket containing the HDF5 files to be accessed.
|
|
||||||
|
|
||||||
FORTRAN Library:
|
|
||||||
----------------
|
|
||||||
- Added new Fortran parameters:
|
|
||||||
|
|
||||||
H5F_LIBVER_ERROR_F
|
|
||||||
H5F_LIBVER_NBOUNDS_F
|
|
||||||
H5F_LIBVER_V18_F
|
|
||||||
H5F_LIBVER_V110_F
|
|
||||||
H5F_LIBVER_V112_F
|
|
||||||
|
|
||||||
- Added new Fortran API: h5pget_libver_bounds_f
|
|
||||||
|
|
||||||
(MSB - 2020/02/11, HDFFV-11018)
|
|
||||||
|
|
||||||
Java Library:
|
|
||||||
----------------
|
|
||||||
- Added ability to test java library with VOLs.
|
|
||||||
|
|
||||||
Created new CMake script that combines the java and vol test scripts.
|
|
||||||
|
|
||||||
(ADB - 2020/02/03, HDFFV-10996)
|
|
||||||
|
|
||||||
- Tests fail for non-English locale.
|
|
||||||
|
|
||||||
In the JUnit tests with a non-English locale, only the part before
|
|
||||||
the decimal comma is replaced by XXXX and this leads to a comparison
|
|
||||||
error. Changed the regex for the Time substitution.
|
|
||||||
|
|
||||||
(ADB - 2020/01/09, HDFFV-10995)
|
|
||||||
|
|
||||||
|
|
||||||
Tools:
|
|
||||||
------
|
|
||||||
- h5diff was updated to use the new reference APIs.
|
|
||||||
|
|
||||||
h5diff uses the new reference APIs to compare references.
|
|
||||||
Attribute references can also be compared.
|
|
||||||
|
|
||||||
(ADB - 2019/12/19, HDFFV-10980)
|
|
||||||
|
|
||||||
- h5dump and h5ls were updated to use the new reference APIs.
|
|
||||||
|
|
||||||
The tools library now use the new reference APIs to inspect a
|
|
||||||
file. Also the DDL spec was updated to reflect the format
|
|
||||||
changes produced with the new APIs. The export API and support
|
|
||||||
functions in the JNI were updated to match.
|
|
||||||
|
|
||||||
|
|
||||||
Other improvements and changes:
|
|
||||||
|
|
||||||
- Hyperslab selection code was reworked to improve performance, getting more
|
|
||||||
than 10x speedup in some cases.
|
|
||||||
|
|
||||||
- The HDF5 Library was enhanced to open files with Unicode names on Windows.
|
|
||||||
|
|
||||||
- Deprecated H5Dvlen_reclaim() and replaced it with H5Treclaim().
|
|
||||||
This routine is meant to be used when resources are internally allocated
|
|
||||||
when reading data, i.e. when using either vlen or new reference types.
|
|
||||||
This is applicable to both attribute and dataset reads.
|
|
||||||
|
|
||||||
- h5repack was fixed to repack datasets with external storage
|
|
||||||
to other types of storage.
|
|
||||||
|
|
||||||
|
|
||||||
Support for new platforms, languages and compilers.
|
|
||||||
=======================================
|
|
||||||
- Added spectrum-mpi with clang, gcc and xl compilers on Linux 3.10.0
|
|
||||||
- Added OpenMPI 3.1 and 4.0 with clang, gcc and Intel compilers on Linux 3.10.0
|
|
||||||
- Added cray-mpich/PrgEnv with gcc and Intel compilers on Linux 4.14.180
|
|
||||||
- Added spectrum mpi with clang, gcc and xl compilers on Linux 4.14.0
|
|
||||||
|
|
||||||
|
|
||||||
Bug Fixes since HDF5-1.12.0-alpha1 release
|
|
||||||
==========================================
|
|
||||||
Library
|
|
||||||
-------
|
|
||||||
- Improved performance when creating a large number of small datasets by
|
|
||||||
retrieving default property values from the API context instead of doing
|
|
||||||
skip list searches.
|
|
||||||
|
|
||||||
(CJH - 2019/12/10, HDFFV-10658)
|
|
||||||
|
|
||||||
- Fixed user-created data access properties not existing in the property list
|
|
||||||
returned by H5Dget_access_plist. Thanks to Steven Varga for submitting a
|
|
||||||
reproducer and a patch.
|
|
||||||
|
|
||||||
(CJH - 2019/12/09, HDFFV-10934)
|
|
||||||
|
|
||||||
- Fixed an assertion failure in the parallel library when collectively
|
|
||||||
filling chunks. As it is required that chunks be written in
|
|
||||||
monotonically non-decreasing order of offset in the file, this assertion
|
|
||||||
was being triggered when the list of chunk file space allocations being
|
|
||||||
passed to the collective chunk filling routine was not sorted according
|
|
||||||
to this particular requirement.
|
|
||||||
|
|
||||||
The addition of a sort of the out of order chunks trades a bit of
|
|
||||||
performance for the elimination of this assertion and of any complaints
|
|
||||||
from MPI implementations about the file offsets used being out of order.
|
|
||||||
|
|
||||||
(JTH - 2019/10/07, HDFFV-10792)
|
|
||||||
|
|
||||||
FORTRAN library:
|
|
||||||
----------------
|
|
||||||
|
|
||||||
- Corrected INTERFACE INTENT(IN) to INTENT(OUT) for buf_size in h5fget_file_image_f.
|
|
||||||
|
|
||||||
(MSB - 2020/2/18, HDFFV-11029)
|
|
||||||
|
|
||||||
Java Library:
|
|
||||||
----------------
|
|
||||||
- Added ability to test java library with VOLs.
|
|
||||||
|
|
||||||
Created new CMake script that combines the java and vol test scripts.
|
|
||||||
|
|
||||||
(ADB - 2020/02/03, HDFFV-10996)
|
|
||||||
|
|
||||||
- Tests fail for non-English locale.
|
|
||||||
|
|
||||||
In the JUnit tests with a non-English locale, only the part before
|
|
||||||
the decimal comma is replaced by XXXX and this leads to a comparison
|
|
||||||
error. Changed the regex for the Time substitution.
|
|
||||||
|
|
||||||
(ADB - 2020/01/09, HDFFV-10995)
|
|
||||||
|
|
||||||
Tools:
|
|
||||||
------
|
|
||||||
- h5repack was fixed to repack the reference attributes properly.
|
|
||||||
The code line that checks if the update of reference inside a compound
|
|
||||||
datatype is misplaced outside the code block loop that carries out the
|
|
||||||
check. In consequence, the next attribute that is not the reference
|
|
||||||
type was repacked again as the reference type and caused the failure of
|
|
||||||
repacking. The fix is to move the corresponding code line to the correct
|
|
||||||
code block.
|
|
||||||
|
|
||||||
(KY -2020/02/10, HDFFV-11014)
|
|
||||||
|
|
||||||
- h5diff was updated to use the new reference APIs.
|
|
||||||
|
|
||||||
h5diff uses the new reference APIs to compare references.
|
|
||||||
Attribute references can also be compared.
|
|
||||||
|
|
||||||
(ADB - 2019/12/19, HDFFV-10980)
|
|
||||||
|
|
||||||
- h5dump and h5ls were updated to use the new reference APIs.
|
|
||||||
|
|
||||||
The tools library now use the new reference APIs to inspect a
|
|
||||||
file. Also the DDL spec was updated to reflect the format
|
|
||||||
changes produced with the new APIs. The export API and support
|
|
||||||
functions in the JNI were updated to match.
|
|
||||||
|
|
||||||
(ADB - 2019/12/06, HDFFV-10876 and HDFFV-10877)
|
|
||||||
|
|
||||||
|
|
||||||
Major Bug Fixes since HDF5-1.10.0 release
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
- For major bug fixes please see HISTORY-1_10_0-1_12_0.txt file
|
|
||||||
|
|
||||||
|
|
||||||
Supported Platforms
|
|
||||||
===================
|
|
||||||
|
|
||||||
Linux 2.6.32-696.16.1.el6.ppc64 gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
|
|
||||||
#1 SMP ppc64 GNU/Linux g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
|
|
||||||
(ostrich) GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
|
|
||||||
IBM XL C/C++ V13.1
|
|
||||||
IBM XL Fortran V15.1
|
|
||||||
|
|
||||||
Linux 3.10.0-327.10.1.el7 GNU C (gcc), Fortran (gfortran), C++ (g++)
|
|
||||||
#1 SMP x86_64 GNU/Linux compilers:
|
|
||||||
(kituo/moohan) Version 4.8.5 20150623 (Red Hat 4.8.5-4)
|
|
||||||
Version 4.9.3, 5.2.0, 7.1.0
|
|
||||||
Intel(R) C (icc), C++ (icpc), Fortran (icc)
|
|
||||||
compilers:
|
|
||||||
Version 17.0.0.098 Build 20160721
|
|
||||||
MPICH 3.1.4
|
|
||||||
|
|
||||||
Linux-3.10.0- spectrum-mpi/rolling-release with cmake>3.10 and
|
|
||||||
862.14.4.1chaos.ch6.ppc64le clang/3.9,8.0
|
|
||||||
#1 SMP ppc64le GNU/Linux gcc/7.3
|
|
||||||
(ray) xl/2016,2019
|
|
||||||
|
|
||||||
Linux 3.10.0- openmpi/3.1,4.0 with cmake>3.10 and
|
|
||||||
957.12.2.1chaos.ch6.x86_64 clang 5.0
|
|
||||||
#1 SMP x86_64 GNU/Linux gcc/7.3,8.2
|
|
||||||
(serrano) intel/17.0,18.0/19.0
|
|
||||||
|
|
||||||
Linux 3.10.0- openmpi/3.1/4.0 with cmake>3.10 and
|
|
||||||
1062.1.1.1chaos.ch6.x86_64 clang/3.9,5.0,8.0
|
|
||||||
#1 SMP x86_64 GNU/Linux gcc/7.3,8.1,8.2
|
|
||||||
(chama,quartz) intel/16.0,18.0,19.0
|
|
||||||
|
|
||||||
Linux 4.4.180-94.100-default cray-mpich/7.7.6 with PrgEnv-*/6.0.5, cmake>3.10 and
|
|
||||||
#1 SMP x86_64 GNU/Linux gcc/7.2.0,8.2.0
|
|
||||||
(mutrino) intel/17.0,18.0
|
|
||||||
|
|
||||||
Linux 4.14.0- spectrum-mpi/rolling-release with cmake>3.10 and
|
|
||||||
49.18.1.bl6.ppc64le clang/6.0,8.0
|
|
||||||
#1 SMP ppc64le GNU/Linux gcc/7.3
|
|
||||||
(lassen) xl/2019
|
|
||||||
|
|
||||||
SunOS 5.11 32- and 64-bit Sun C 5.12 SunOS_sparc
|
|
||||||
(emu) Sun Fortran 95 8.6 SunOS_sparc
|
|
||||||
Sun C++ 5.12 SunOS_sparc
|
|
||||||
|
|
||||||
Windows 7 x64 Visual Studio 2015 w/ Intel C, Fortran 2018 (cmake)
|
|
||||||
Visual Studio 2015 w/ MSMPI 10 (cmake)
|
|
||||||
|
|
||||||
Windows 10 x64 Visual Studio 2015 w/ Intel Fortran 18 (cmake)
|
|
||||||
Visual Studio 2017 w/ Intel Fortran 19 (cmake)
|
|
||||||
Visual Studio 2019 w/ Intel Fortran 19 (cmake)
|
|
||||||
|
|
||||||
macOS 10.13.6 High Sierra Apple LLVM version 10.0.0 (clang/clang++-1000.10.44.4)
|
|
||||||
64-bit gfortran GNU Fortran (GCC) 6.3.0
|
|
||||||
(bear) Intel icc/icpc/ifort version 19.0.4
|
|
||||||
|
|
||||||
macOS 10.14.6 Mohave Apple LLVM version 10.0.1 (clang/clang++-1001.0.46.4)
|
|
||||||
64-bit gfortran GNU Fortran (GCC) 6.3.0
|
|
||||||
(bobcat) Intel icc/icpc/ifort version 19.0.4
|
|
||||||
|
|
||||||
|
|
||||||
Tested Configuration Features Summary
|
|
||||||
=====================================
|
|
||||||
|
|
||||||
In the tables below
|
|
||||||
y = tested
|
|
||||||
n = not tested in this release
|
|
||||||
C = Cluster
|
|
||||||
W = Workstation
|
|
||||||
x = not working in this release
|
|
||||||
dna = does not apply
|
|
||||||
( ) = footnote appears below second table
|
|
||||||
<blank> = testing incomplete on this feature or platform
|
|
||||||
|
|
||||||
Platform C F90/ F90 C++ zlib SZIP
|
|
||||||
parallel F2003 parallel
|
|
||||||
SunOS 5.11 32-bit n y/y n y y y
|
|
||||||
SunOS 5.11 64-bit n y/n n y y y
|
|
||||||
Windows 7 y y/y n y y y
|
|
||||||
Windows 7 x64 y y/y y y y y
|
|
||||||
Windows 7 Cygwin n y/n n y y y
|
|
||||||
Windows 7 x64 Cygwin n y/n n y y y
|
|
||||||
Windows 10 y y/y n y y y
|
|
||||||
Windows 10 x64 y y/y n y y y
|
|
||||||
macOS 10.13.6 64-bit n y/y n y y ?
|
|
||||||
macOS 10.14.6 64-bit n y/y n y y ?
|
|
||||||
CentOS 6.7 Linux 2.6.18 x86_64 GNU n y/y n y y y
|
|
||||||
CentOS 6.7 Linux 2.6.18 x86_64 Intel n y/y n y y y
|
|
||||||
CentOS 6.7 Linux 2.6.32 x86_64 PGI n y/y n y y y
|
|
||||||
CentOS 7.2 Linux 2.6.32 x86_64 GNU y y/y y y y y
|
|
||||||
CentOS 7.2 Linux 2.6.32 x86_64 Intel n y/y n y y y
|
|
||||||
Linux 2.6.32-573.18.1.el6.ppc64 n y/n n y y y
|
|
||||||
|
|
||||||
|
|
||||||
Platform Shared Shared Shared Thread-
|
|
||||||
C libs F90 libs C++ libs safe
|
|
||||||
SunOS 5.11 32-bit y y y y
|
|
||||||
SunOS 5.11 64-bit y y y y
|
|
||||||
Windows 7 y y y y
|
|
||||||
Windows 7 x64 y y y y
|
|
||||||
Windows 7 Cygwin n n n y
|
|
||||||
Windows 7 x64 Cygwin n n n y
|
|
||||||
Windows 10 y y y y
|
|
||||||
Windows 10 x64 y y y y
|
|
||||||
macOS 10.13.6 64-bit y n y y
|
|
||||||
macOS 10.14.6 64-bit y n y y
|
|
||||||
CentOS 6.7 Linux 2.6.18 x86_64 GNU y y y y
|
|
||||||
CentOS 6.7 Linux 2.6.18 x86_64 Intel y y y n
|
|
||||||
CentOS 6.7 Linux 2.6.32 x86_64 PGI y y y n
|
|
||||||
CentOS 7.2 Linux 2.6.32 x86_64 GNU y y y n
|
|
||||||
CentOS 7.2 Linux 2.6.32 x86_64 Intel y y y n
|
|
||||||
Linux 2.6.32-573.18.1.el6.ppc64 y y y n
|
|
||||||
|
|
||||||
Compiler versions for each platform are listed in the preceding
|
|
||||||
"Supported Platforms" table.
|
|
||||||
|
|
||||||
|
|
||||||
More Tested Platforms
|
|
||||||
=====================
|
|
||||||
The following platforms are not supported but have been tested for this release.
|
|
||||||
|
|
||||||
Linux 2.6.32-573.22.1.el6 GNU C (gcc), Fortran (gfortran), C++ (g++)
|
|
||||||
#1 SMP x86_64 GNU/Linux compilers:
|
|
||||||
(mayll/platypus) Version 4.4.7 20120313
|
|
||||||
Version 4.9.3, 5.3.0, 6.2.0
|
|
||||||
PGI C, Fortran, C++ for 64-bit target on
|
|
||||||
x86-64;
|
|
||||||
Version 17.10-0
|
|
||||||
Intel(R) C (icc), C++ (icpc), Fortran (icc)
|
|
||||||
compilers:
|
|
||||||
Version 17.0.4.196 Build 20170411
|
|
||||||
MPICH 3.1.4 compiled with GCC 4.9.3
|
|
||||||
|
|
||||||
Linux 3.10.0-327.18.2.el7 GNU C (gcc) and C++ (g++) compilers
|
|
||||||
#1 SMP x86_64 GNU/Linux Version 4.8.5 20150623 (Red Hat 4.8.5-4)
|
|
||||||
(jelly) with NAG Fortran Compiler Release 6.1(Tozai)
|
|
||||||
GCC Version 7.1.0
|
|
||||||
OpenMPI 3.0.0-GCC-7.2.0-2.29
|
|
||||||
Intel(R) C (icc) and C++ (icpc) compilers
|
|
||||||
Version 17.0.0.098 Build 20160721
|
|
||||||
with NAG Fortran Compiler Release 6.1(Tozai)
|
|
||||||
PGI C (pgcc), C++ (pgc++), Fortran (pgf90)
|
|
||||||
compilers:
|
|
||||||
Version 18.4, 19.4
|
|
||||||
MPICH 3.3
|
|
||||||
OpenMPI 2.1.5, 3.1.3, 4.0.0
|
|
||||||
|
|
||||||
Fedora30 5.3.11-200.fc30.x86_64
|
|
||||||
#1 SMP x86_64 GNU/Linux GNU gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1 20190827)
|
|
||||||
GNU Fortran (GCC) 9.2.1 20190827 (Red Hat 9.2.1 20190827)
|
|
||||||
(cmake and autotools)
|
|
||||||
|
|
||||||
Mac OS X El Capitan 10.11.6 Apple LLVM version 7.3.0 (clang/clang++-703.0.29)
|
|
||||||
64-bit gfortran GNU Fortran (GCC) 5.2.0
|
|
||||||
(osx1011dev/osx1011test) Intel icc/icpc/ifort version 16.0.2
|
|
||||||
|
|
||||||
macOS 10.12.6 Sierra Apple LLVM version 9.0.0 (clang/clang++-900.0.39.2)
|
|
||||||
64-bit gfortran GNU Fortran (GCC) 7.4.0
|
|
||||||
(kite) Intel icc/icpc/ifort version 17.0.8
|
|
||||||
|
|
||||||
|
|
||||||
Known Problems
|
|
||||||
==============
|
|
||||||
CMake files do not behave correctly with paths containing spaces.
|
|
||||||
Do not use spaces in paths because the required escaping for handling spaces
|
|
||||||
results in very complex and fragile build files.
|
|
||||||
ADB - 2019/05/07
|
|
||||||
|
|
||||||
At present, metadata cache images may not be generated by parallel
|
|
||||||
applications. Parallel applications can read files with metadata cache
|
|
||||||
images, but since this is a collective operation, a deadlock is possible
|
|
||||||
if one or more processes do not participate.
|
|
||||||
|
|
||||||
Known problems in previous releases can be found in the HISTORY*.txt files
|
|
||||||
in the HDF5 source, and in the HDF5 Jira database, available at
|
|
||||||
https://jira.hdfgroup.org/. Please register at https://www.hdfgroup.org to
|
|
||||||
create a free account for accessing the Jira database. Please report any
|
|
||||||
new problems found to help@hdfgroup.org.
|
|
||||||
|
|
||||||
|
|
||||||
CMake vs. Autotools installations
|
|
||||||
=================================
|
|
||||||
While both build systems produce similar results, there are differences.
|
|
||||||
Each system produces the same set of folders on linux (only CMake works
|
|
||||||
on standard Windows); bin, include, lib and share. Autotools places the
|
|
||||||
COPYING and RELEASE.txt file in the root folder, CMake places them in
|
|
||||||
the share folder.
|
|
||||||
|
|
||||||
The bin folder contains the tools and the build scripts. Additionally, CMake
|
|
||||||
creates dynamic versions of the tools with the suffix "-shared". Autotools
|
|
||||||
installs one set of tools depending on the "--enable-shared" configuration
|
|
||||||
option.
|
|
||||||
build scripts
|
|
||||||
-------------
|
|
||||||
Autotools: h5c++, h5cc, h5fc
|
|
||||||
CMake: h5c++, h5cc, h5hlc++, h5hlcc
|
|
||||||
|
|
||||||
The include folder holds the header files and the fortran mod files. CMake
|
|
||||||
places the fortran mod files into separate shared and static subfolders,
|
|
||||||
while Autotools places one set of mod files into the include folder. Because
|
|
||||||
CMake produces a tools library, the header files for tools will appear in
|
|
||||||
the include folder.
|
|
||||||
|
|
||||||
The lib folder contains the library files, and CMake adds the pkgconfig
|
|
||||||
subfolder with the hdf5*.pc files used by the bin/build scripts created by
|
|
||||||
the CMake build. CMake separates the C interface code from the fortran code by
|
|
||||||
creating C-stub libraries for each Fortran library. In addition, only CMake
|
|
||||||
installs the tools library. The names of the szip libraries are different
|
|
||||||
between the build systems.
|
|
||||||
|
|
||||||
The share folder will have the most differences because CMake builds include
|
|
||||||
a number of CMake specific files for support of CMake's find_package and support
|
|
||||||
for the HDF5 Examples CMake project.
|
|
||||||
|
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
25
release_docs/NEWSLETTER.txt
Normal file
25
release_docs/NEWSLETTER.txt
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
INTRODUCTION
|
||||||
|
============
|
||||||
|
|
||||||
|
This purpose of this document is to contain entries that can be used to quickly
|
||||||
|
produce a release newsletter. When something is added to the library that is
|
||||||
|
"newsletter worthy" (i.e., new feature, CVE fix, etc.) a summary note should
|
||||||
|
be added here.
|
||||||
|
|
||||||
|
The format should look like this:
|
||||||
|
|
||||||
|
* SUMMARY OF NEWSLETTER-WORTHY THING
|
||||||
|
|
||||||
|
Here is where you describe the summary. Summarize the feature, fix, or
|
||||||
|
change in general language. Remember, RELEASE.txt is for communicating
|
||||||
|
technical specifics. Text entered here is more like advertising.
|
||||||
|
|
||||||
|
(GitHub #123, #125)
|
||||||
|
|
||||||
|
The GitHub #s could be relevant issues or PRs. They will probably not appear
|
||||||
|
in the final newsletter, but are so that the person writing the newsletter
|
||||||
|
has easy access to context if they have questions.
|
||||||
|
|
||||||
|
Every entry in RELEASE.txt does NOT require an entry here. The newsletter is
|
||||||
|
for communicating major changes that are of interest to anyone. Minor bugfixes,
|
||||||
|
memory leak fixes, etc. do not require entries.
|
102
release_docs/README.md
Normal file
102
release_docs/README.md
Normal file
@ -0,0 +1,102 @@
|
|||||||
|
# The `release_docs` directory
|
||||||
|
|
||||||
|
## Intro
|
||||||
|
|
||||||
|
This directory contains instructions for building and using the library as
|
||||||
|
well as the HDF5 history files.
|
||||||
|
|
||||||
|
## HISTORY files
|
||||||
|
|
||||||
|
The `HISTORY` files contain the history of this branch of HDF5. They fall into
|
||||||
|
three categories.
|
||||||
|
|
||||||
|
### HISTORY-\[VERSION 1\]-\[VERSION 2\].txt
|
||||||
|
|
||||||
|
These files are created when we release a new major version and include all
|
||||||
|
the changes that were made to the `develop` branch while creating a major release.
|
||||||
|
|
||||||
|
### HISTORY-\[VERSION\].txt
|
||||||
|
|
||||||
|
This file contains the changes that were made to a maintenance branch since
|
||||||
|
it split off from `develop`. It will also be found in the `develop` branch
|
||||||
|
when experimental releases have been created.
|
||||||
|
|
||||||
|
### RELEASE.txt
|
||||||
|
|
||||||
|
This is the changelog for the current version of the library.
|
||||||
|
|
||||||
|
For a MAJOR release (or in `develop`) this files lists all the changes since the
|
||||||
|
last major version. For a MINOR release (or in a maintenance branch), this file
|
||||||
|
lists all the changes since the last release in the maintenance branch.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
* The file for HDF5 1.14.0 includes all the changes since HDF5 1.12.0
|
||||||
|
* The file for HDF5 1.10.9 includes all the changes since HDF5 1.10.8
|
||||||
|
* The file in `develop` includes all the changes since the last major release
|
||||||
|
* The file in `hdf5_1_14` includes all the changes since the last minor HDF5 1.14 release
|
||||||
|
|
||||||
|
Note that we make no effort to bring maintenance branch `HISTORY` files back to
|
||||||
|
develop. If you want to compare, say, 1.10.4 with 1.12.3, you'd have to get
|
||||||
|
the history files from those releases and compare them by hand.
|
||||||
|
|
||||||
|
## Creating new releases
|
||||||
|
|
||||||
|
### MAJOR release
|
||||||
|
|
||||||
|
* If there were experimental releases, merge the experimental `HISTORY` file
|
||||||
|
and the current `RELEASE.txt` by category to create a separate, unified
|
||||||
|
file that ignores the experimental releases. Don't check this in yet or
|
||||||
|
clobber any existing `HISTORY`/`RELEASE` files, but put it someplace handy for
|
||||||
|
use in later steps.
|
||||||
|
|
||||||
|
* Create the new maintenance branch
|
||||||
|
|
||||||
|
In develop:
|
||||||
|
* Create the new `HISTORY-\[VERSION 1\]-\[VERSION 2\].txt` file
|
||||||
|
* If there is an experimental `HISTORY` file, add `RELEASE.txt` to the beginning of it and use that
|
||||||
|
* Otherwise, start with `RELEASE.txt`
|
||||||
|
* Add the introduction boilerplate like in the other `HISTORY` files (TOC, etc.)
|
||||||
|
* Delete any experimental `HISTORY` file
|
||||||
|
* Clear out `RELEASE.txt`
|
||||||
|
|
||||||
|
Note that we're KEEPING any experimental release history information in the
|
||||||
|
`HISTORY-\[VERSION 1\]-\[VERSION 2\].txt` file, so do NOT use the merged file in
|
||||||
|
the above steps!
|
||||||
|
|
||||||
|
In the new maintenance branch:
|
||||||
|
* Create the new `HISTORY-\[VERSION\].txt` file
|
||||||
|
* If there is an experimental `HISTORY` file use the combined file you created earlier
|
||||||
|
* Otherwise, start with `RELEASE.txt`
|
||||||
|
* Add the introduction boilerplate like in the other `HISTORY` files (TOC, etc.)
|
||||||
|
* Delete any experimental `HISTORY` file
|
||||||
|
* Clear out `RELEASE.txt`
|
||||||
|
|
||||||
|
* Create the new release branch
|
||||||
|
|
||||||
|
In the new release branch:
|
||||||
|
* If there were experimental releases, use the combined file you created earlier as `RELEASE.txt`
|
||||||
|
* Otherwise the `RELEASE.txt` will be used as-is
|
||||||
|
|
||||||
|
### MINOR release
|
||||||
|
|
||||||
|
* Create the release branch
|
||||||
|
|
||||||
|
In the maintenance branch:
|
||||||
|
* Add the contents of `RELEASE.txt` to the beginnnig of `HISTORY-\[VERSION\].txt`
|
||||||
|
* Clear out `RELEASE.txt`
|
||||||
|
|
||||||
|
### EXPERIMENTAL release
|
||||||
|
|
||||||
|
* Add the contents of `RELEASE.txt` to the beginnnig of `HISTORY-\[VERSION\].txt`
|
||||||
|
* Clear out `RELEASE.txt`
|
||||||
|
|
||||||
|
## INSTALL files
|
||||||
|
|
||||||
|
These files include instructions for building and installing HDF5 on various
|
||||||
|
platforms.
|
||||||
|
|
||||||
|
## USING files
|
||||||
|
|
||||||
|
These files document how to build HDF5 applications with an installed HDF5
|
||||||
|
library.
|
@ -21,7 +21,7 @@ The official HDF5 releases can be obtained from:
|
|||||||
|
|
||||||
https://www.hdfgroup.org/downloads/hdf5/
|
https://www.hdfgroup.org/downloads/hdf5/
|
||||||
|
|
||||||
Changes from Release to Release and New Features in the HDF5-1.13.x release series
|
Changes from release to release and new features in the HDF5-1.14.x release series
|
||||||
can be found at:
|
can be found at:
|
||||||
|
|
||||||
https://portal.hdfgroup.org/display/HDF5/Release+Specific+Information
|
https://portal.hdfgroup.org/display/HDF5/Release+Specific+Information
|
||||||
@ -36,7 +36,7 @@ CONTENTS
|
|||||||
|
|
||||||
- New Features
|
- New Features
|
||||||
- Support for new platforms and languages
|
- Support for new platforms and languages
|
||||||
- Bug Fixes since HDF5-1.13.3
|
- Bug Fixes since HDF5-1.14.0
|
||||||
- Platforms Tested
|
- Platforms Tested
|
||||||
- Known Problems
|
- Known Problems
|
||||||
- CMake vs. Autotools installations
|
- CMake vs. Autotools installations
|
||||||
@ -47,108 +47,13 @@ New Features
|
|||||||
|
|
||||||
Configuration:
|
Configuration:
|
||||||
-------------
|
-------------
|
||||||
- Removal of MPE support
|
-
|
||||||
|
|
||||||
The ability to build with MPE instrumentation has been removed along with
|
|
||||||
the following configure options:
|
|
||||||
|
|
||||||
Autotools:
|
|
||||||
--with-mpe=
|
|
||||||
|
|
||||||
CMake has never supported building with MPE support.
|
|
||||||
|
|
||||||
(DER - 2022/11/08)
|
|
||||||
|
|
||||||
- Removal of dmalloc support
|
|
||||||
|
|
||||||
The ability to build with dmalloc support has been removed along with
|
|
||||||
the following configure options:
|
|
||||||
|
|
||||||
Autotools:
|
|
||||||
--with-dmalloc=
|
|
||||||
|
|
||||||
CMake:
|
|
||||||
HDF5_ENABLE_USING_DMALLOC
|
|
||||||
|
|
||||||
(DER - 2022/11/08)
|
|
||||||
|
|
||||||
- Removal of memory allocation sanity checks configure options
|
|
||||||
|
|
||||||
With the removal of the memory allocation sanity checks feature, the
|
|
||||||
following configure options are no longer necessary and have been
|
|
||||||
removed:
|
|
||||||
|
|
||||||
Autotools:
|
|
||||||
--enable-memory-alloc-sanity-check
|
|
||||||
|
|
||||||
CMake:
|
|
||||||
HDF5_MEMORY_ALLOC_SANITY_CHECK
|
|
||||||
HDF5_ENABLE_MEMORY_STATS
|
|
||||||
|
|
||||||
(DER - 2022/11/03)
|
|
||||||
|
|
||||||
Library:
|
Library:
|
||||||
--------
|
--------
|
||||||
- Overhauled the Virtual Object Layer (VOL)
|
-
|
||||||
|
|
||||||
The virtual object layer (VOL) was added in HDF5 1.12.0 but the initial
|
|
||||||
implementation required API-breaking changes to better support optional
|
|
||||||
operations and pass-through VOL connectors. The original VOL API is
|
|
||||||
now considered deprecated and VOL users and connector authors should
|
|
||||||
target the 1.14 VOL API.
|
|
||||||
|
|
||||||
The specific changes are too extensive to document in a release note, so
|
|
||||||
VOL users and connector authors should consult the updated VOL connector
|
|
||||||
author's guide and the 1.12-1.14 VOL migration guide.
|
|
||||||
|
|
||||||
(DER - 2022/12/28)
|
|
||||||
|
|
||||||
- H5VLquery_optional() signature change
|
|
||||||
|
|
||||||
The last parameter of this API call has changed from a pointer to hbool_t
|
|
||||||
to a pointer to uint64_t. Due to the changes in how optional operations
|
|
||||||
are handled in the 1.14 VOL API, we cannot make the old API call work
|
|
||||||
with the new scheme, so there is no API compatibility macro for it.
|
|
||||||
|
|
||||||
(DER - 2022/12/28)
|
|
||||||
|
|
||||||
- H5I_free_t callback signature change
|
|
||||||
|
|
||||||
In order to support asynchronous operations and future IDs, the signature
|
|
||||||
of the H5I_free_t callback has been modified to take a second 'request'
|
|
||||||
parameter. Due to the nature of the internal library changes, no API
|
|
||||||
compatibility macro is available for this change.
|
|
||||||
|
|
||||||
(DER - 2022/12/28)
|
|
||||||
|
|
||||||
- Fix for CVE-2019-8396
|
|
||||||
|
|
||||||
Malformed HDF5 files may have truncated content which does not match
|
|
||||||
the expected size. When H5O__pline_decode() attempts to decode these it
|
|
||||||
may read past the end of the allocated space leading to heap overflows
|
|
||||||
as bounds checking is incomplete.
|
|
||||||
|
|
||||||
The fix ensures each element is within bounds before reading.
|
|
||||||
|
|
||||||
(2022/11/09 - HDFFV-10712, CVE-2019-8396, GitHub #2209)
|
|
||||||
|
|
||||||
- Removal of memory allocation sanity checks feature
|
|
||||||
|
|
||||||
This feature added heap canaries and statistics tracking for internal
|
|
||||||
library memory operations. Unfortunately, the heap canaries caused
|
|
||||||
problems when library memory operations were mixed with standard C
|
|
||||||
library memory operations (such as in the filter pipeline, where
|
|
||||||
buffers may have to be reallocated). Since any platform with a C
|
|
||||||
compiler also usually has much more sophisticated memory sanity
|
|
||||||
checking tools than the HDF5 library provided (e.g., valgrind), we
|
|
||||||
have decided to to remove the feature entirely.
|
|
||||||
|
|
||||||
In addition to the configure changes described above, this also removes
|
|
||||||
the following from the public API:
|
|
||||||
H5get_alloc_stats()
|
|
||||||
H5_alloc_stats_t
|
|
||||||
|
|
||||||
(DER - 2022/11/03)
|
|
||||||
|
|
||||||
Parallel Library:
|
Parallel Library:
|
||||||
-----------------
|
-----------------
|
||||||
@ -198,132 +103,13 @@ New Features
|
|||||||
Support for new platforms, languages and compilers
|
Support for new platforms, languages and compilers
|
||||||
==================================================
|
==================================================
|
||||||
-
|
-
|
||||||
|
|
||||||
Bug Fixes since HDF5-1.13.3 release
|
|
||||||
|
Bug Fixes since HDF5-1.14.0 release
|
||||||
===================================
|
===================================
|
||||||
Library
|
Library
|
||||||
-------
|
-------
|
||||||
- Seg fault on file close
|
-
|
||||||
|
|
||||||
h5debug fails at file close with core dump on a file that has an
|
|
||||||
illegal file size in its cache image. In H5F_dest(), the library
|
|
||||||
performs all the closing operations for the file and keeps track of
|
|
||||||
the error encountered when reading the file cache image.
|
|
||||||
At the end of the routine, it frees the file's file structure and
|
|
||||||
returns error. Due to the error return, the file object is not removed
|
|
||||||
from the ID node table. This eventually causes assertion failure in
|
|
||||||
H5VL__native_file_close() when the library finally exits and tries to
|
|
||||||
access that file object in the table for closing.
|
|
||||||
|
|
||||||
The closing routine, H5F_dest(), will not free the file structure if
|
|
||||||
there is error, keeping a valid file structure in the ID node table.
|
|
||||||
It will be freed later in H5VL__native_file_close() when the
|
|
||||||
library exits and terminates the file package.
|
|
||||||
|
|
||||||
(VC - 2022/12/14, HDFFV-11052, CVE-2020-10812)
|
|
||||||
|
|
||||||
- Fix CVE-2018-13867 / GHSA-j8jr-chrh-qfrf
|
|
||||||
|
|
||||||
Validate location (offset) of the accumulated metadata when comparing.
|
|
||||||
|
|
||||||
Initially, the accumulated metadata location is initialized to HADDR_UNDEF
|
|
||||||
- the highest available address. Bogus input files may provide a location
|
|
||||||
or size matching this value. Comparing this address against such bogus
|
|
||||||
values may provide false positives. Thus make sure, the value has been
|
|
||||||
initialized or fail the comparison early and let other parts of the
|
|
||||||
code deal with the bogus address/size.
|
|
||||||
Note: To avoid unnecessary checks, it is assumed that if the 'dirty'
|
|
||||||
member in the same structure is true the location is valid.
|
|
||||||
|
|
||||||
(EFE - 2022/10/10 GH-2230)
|
|
||||||
|
|
||||||
- Fix CVE-2018-16438 / GHSA-9xmm-cpf8-rgmx
|
|
||||||
|
|
||||||
Make sure info block for external links has at least 3 bytes.
|
|
||||||
|
|
||||||
According to the specification, the information block for external links
|
|
||||||
contains 1 byte of version/flag information and two 0 terminated strings
|
|
||||||
for the object linked to and the full path.
|
|
||||||
Although not very useful, the minimum string length for each (with
|
|
||||||
terminating 0) would be one byte.
|
|
||||||
Checking this helps to avoid SEGVs triggered by bogus files.
|
|
||||||
|
|
||||||
(EFE - 2022/10/09 GH-2233)
|
|
||||||
|
|
||||||
- CVE-2021-46244 / GHSA-vrxh-5gxg-rmhm
|
|
||||||
|
|
||||||
Compound datatypes may not have members of size 0
|
|
||||||
|
|
||||||
A member size of 0 may lead to an FPE later on as reported in
|
|
||||||
CVE-2021-46244. To avoid this, check for this as soon as the
|
|
||||||
member is decoded.
|
|
||||||
|
|
||||||
(EFE - 2022/10/05 GEH-2242)
|
|
||||||
|
|
||||||
|
|
||||||
- Fix CVE-2021-45830 / GHSA-5h2h-fjjr-x9m2
|
|
||||||
|
|
||||||
Make H5O__fsinfo_decode() more resilient to out-of-bound reads.
|
|
||||||
|
|
||||||
When decoding a file space info message in H5O__fsinfo_decode() make
|
|
||||||
sure each element to be decoded is still within the message. Malformed
|
|
||||||
hdf5 files may have trunkated content which does not match the
|
|
||||||
expected size. Checking this will prevent attempting to decode
|
|
||||||
unrelated data and heap overflows. So far, only free space manager
|
|
||||||
address data was checked before decoding.
|
|
||||||
|
|
||||||
(EFE - 2022/10/05 GH-2228)
|
|
||||||
|
|
||||||
- Fix CVE-2021-46242 / GHSA-x9pw-hh7v-wjpf
|
|
||||||
|
|
||||||
When evicting driver info block, NULL the corresponding entry.
|
|
||||||
|
|
||||||
Since H5C_expunge_entry() called (from H5AC_expunge_entry()) sets the flag
|
|
||||||
H5C__FLUSH_INVALIDATE_FLAG, the driver info block will be freed. NULLing
|
|
||||||
the pointer in f->shared->drvinfo will prevent use-after-free when it is
|
|
||||||
used in other functions (like H5F__dest()) - as other places will check
|
|
||||||
whether the pointer is initialized before using its value.
|
|
||||||
|
|
||||||
(EFE - 2022/09/29 GH-2254)
|
|
||||||
|
|
||||||
- Fix CVE-2021-45833 / GHSA-x57p-jwp6-4v79
|
|
||||||
|
|
||||||
Report error if dimensions of chunked storage in data layout < 2
|
|
||||||
|
|
||||||
For Data Layout Messages version 1 & 2 the specification state
|
|
||||||
that the value stored in the data field is 1 greater than the
|
|
||||||
number of dimensions in the dataspace. For version 3 this is
|
|
||||||
not explicitly stated but the implementation suggests it to be
|
|
||||||
the case.
|
|
||||||
Thus the set value needs to be at least 2. For dimensionality
|
|
||||||
< 2 an out-of-bounds access occurs.
|
|
||||||
|
|
||||||
(EFE - 2022/09/28 GH-2240)
|
|
||||||
|
|
||||||
- Fix CVE-2018-14031 / GHSA-2xc7-724c-r36j
|
|
||||||
|
|
||||||
Parent of enum datatype message must have the same size as the
|
|
||||||
enum datatype message itself.
|
|
||||||
Functions accessing the enumeration values use the size of the
|
|
||||||
enumeration datatype to determine the size of each element and
|
|
||||||
how much data to copy.
|
|
||||||
Thus the size of the enumeration and its parent need to match.
|
|
||||||
Check in H5O_dtype_decode_helper() to avoid unpleasant surprises
|
|
||||||
later.
|
|
||||||
|
|
||||||
(EFE - 2022/09/28 GH-2236)
|
|
||||||
|
|
||||||
- Fix CVE-2018-17439 / GHSA-vcxv-vp43-rch7
|
|
||||||
|
|
||||||
H5IMget_image_info(): Make sure to not exceed local array size
|
|
||||||
|
|
||||||
Malformed hdf5 files may provide more dimensions than the array dim[] in
|
|
||||||
H5IMget_image_info() is able to hold. Check number of elements first by calling
|
|
||||||
H5Sget_simple_extent_dims() with NULL for both 'dims' and 'maxdims' arguments.
|
|
||||||
This will cause the function to return only the number of dimensions.
|
|
||||||
The fix addresses a stack overflow on write.
|
|
||||||
|
|
||||||
(EFE - 2022/09/27 HDFFV-10589, GH-2226)
|
|
||||||
|
|
||||||
|
|
||||||
Java Library
|
Java Library
|
||||||
@ -333,49 +119,12 @@ Bug Fixes since HDF5-1.13.3 release
|
|||||||
|
|
||||||
Configuration
|
Configuration
|
||||||
-------------
|
-------------
|
||||||
- Remove Javadoc generation
|
-
|
||||||
|
|
||||||
The use of doxygen now supersedes the requirement to build javadocs. We do not
|
|
||||||
have the resources to continue to support two documentation methods and have
|
|
||||||
chosen doxygen as our standard.
|
|
||||||
|
|
||||||
(ADB - 2022/12/19)
|
|
||||||
|
|
||||||
- Change the default for building the high-level tools
|
|
||||||
|
|
||||||
The gif2hdf5 and hdf2gif high-level tools are deprecated and will be removed
|
|
||||||
in a future release. The default build setting for them have been changed from enabled
|
|
||||||
to disabled. A user can enable the build of these tools if needed.
|
|
||||||
autotools: --enable-hlgiftools
|
|
||||||
cmake: HDF5_BUILD_HL_GIF_TOOLS=ON
|
|
||||||
|
|
||||||
(ADB - 2022/12/16)
|
|
||||||
|
|
||||||
- Change the settings of the *pc files to use the correct format
|
|
||||||
|
|
||||||
The pkg-config files generated by CMake uses incorrect syntax for the 'Requires'
|
|
||||||
settings. Changing the set to use 'lib-name = version' instead 'lib-name-version'
|
|
||||||
fixes the issue
|
|
||||||
|
|
||||||
(ADB - 2022/12/06 HDFFV-11355)
|
|
||||||
|
|
||||||
- Move MPI libraries link from PRIVATE to PUBLIC
|
|
||||||
|
|
||||||
The install dependencies were not including the need for MPI libraries when
|
|
||||||
an application or library was built with the C library. Also updated the
|
|
||||||
CMake target link command to use the newer style MPI::MPI_C link variable.
|
|
||||||
|
|
||||||
(ADB - 2022/10/27)
|
|
||||||
|
|
||||||
|
|
||||||
Tools
|
Tools
|
||||||
-----
|
-----
|
||||||
- Fix h5repack to only print output when verbose option is selected
|
-
|
||||||
|
|
||||||
When timing option was added to h5repack, the check for verbose was
|
|
||||||
incorrectly implemented.
|
|
||||||
|
|
||||||
(ADB - 2022/12/02, GH #2270)
|
|
||||||
|
|
||||||
|
|
||||||
Performance
|
Performance
|
||||||
@ -387,6 +136,7 @@ Bug Fixes since HDF5-1.13.3 release
|
|||||||
-----------
|
-----------
|
||||||
-
|
-
|
||||||
|
|
||||||
|
|
||||||
High-Level Library
|
High-Level Library
|
||||||
------------------
|
------------------
|
||||||
-
|
-
|
||||||
|
Loading…
Reference in New Issue
Block a user