Update for 2.2.0

[bmribler]

No description provided.

[gheber]

Why is removing https:// necessary?

[bmribler]

@gheber So that it won't try to go to the location which is not valid.

[gheber]

This strikes me as an "original," albeit somewhat bizarre, approach. What is the underlying engineering problem?

[bmribler]

Do you have other suggestions to avoid reader clicking on an invalid URL?

[gheber]

I'm still trying to understand the problem we are trying to solve. If we don't want someone to click on a URL, why is there a URL in the first place?

[bmribler]

Because it is a wget example for user to enter the command

[jhendersonHDF]

@gheber See the "Methods to obtain (gz file)" section of https://support.hdfgroup.org/documentation/hdf5/latest/rel_spec_2x.html

[bmribler]

@gheber Please see my latest attempt on fixing this.

[gheber]

Still broken (=not rendering as intended). Prefix the URL with %, i.e.,

...
wget %https://github.com/HDFGroup/hdf5/releases/download/${PACKAGEVERSION}/<distribution>.tar.gz
...

Are you using Claude?

[brtnfld]

I really want us to re-examine the version churn we currently have; it just leads to mistakes down the road. As was the case with which previous version the ABI was being compared to for the reports. Case in point, this has 8 hardcoded version strings across two .dox files, and hdf5_2x.dox is already internally inconsistent today, with some lines pointing at hdf5_2.1.1 while other lines still say 2.1.0. The 2.1.1 patch release updated one of eight.

The docs already have the machinery: Doxyfile.in has an empty ALIASES tag and is run through configure_file(... @only) at docs/doxygen/CMakeLists.txt, and CMake already parses the version out of src/H5public.h into HDF5_PACKAGE_VERSION, so the release version is known at configure time, but it just isn't exposed to Doxygen.

Please rework this PR to address this; we want to update the docs for free.

[bmribler]

Scot, Larry and I talked and we will work on this in the morning.

[jhendersonHDF]

I think we're going to need a different solution than this, because there's no good value to set this to when a major version bump happens and it also adds another thing to be manually maintained. Seems like we could simply calculate this at build time by taking the current version, doing something special for the case where both the minor and patch versions are 0 (implying a major version bump) and otherwise subtract one from the patch number if not 0, else subtract one from the minor version if not 0.

[bmribler]

@lrknox simplified the PREVIOUS_VER alias for this release, but that will need to be revisited for more complex solution.

[bmribler]

@brtnfld, we reworked the PR to automate the current release.

[brtnfld]

Found two follow-up issues after merge, both around the new \CURRENT_VER/\PREVIOUS_VER aliases:

1. \PREVIOUS_VER is used for two different meanings

In hdf5_2x.dox, sec_rel_spec_2x_migrate still links its three CHANGELOG references through \PREVIOUS_VER:

<a href="https://\SRCURLALL/hdf5_\PREVIOUS_VER/release_docs/CHANGELOG.md">CHANGELOG.md</a>

But that section (H5Dread_chunk(), H5Tdecode(), H5Iregister_type() signature changes, the aws-c-s3 ROS3 backend swap) documents 2.0.0-era changes — confirmed against sw_changes_2.x.dox's "Release 2.0.0 versus Release 1.14.6" section, which lists these exact APIs. \PREVIOUS_VER is 2.1.1, so these links now point at the 2.1.1 CHANGELOG, which doesn't cover this content, and will drift to a new (still wrong) target every future release.

This predates this PR — the link was already hardcoded to 2.1.0 before (also wrong, should've been 2.0.0) — but converting it to \PREVIOUS_VER turns a static mistake into a perpetually-drifting one. Suggest pinning these three links to 2.0.0 explicitly (or a dedicated alias) rather than \PREVIOUS_VER.

2. ABI baseline mismatch between the two files

• sw_changes_2.x.dox (new, hardcoded): "Compatibility reports for Release 2.2.0 versus Release 2.1.0"
• hdf5_2x.dox (via alias): "ABI/API Compatibility Reports between 2.2.0 and 2.1.1"

Checked actual release history (gh release list): 2.0.0 → 2.1.0 (Mar 3) → 2.1.1 (Mar 23, latest) → 2.2.0. The real predecessor of 2.2.0 is 2.1.1, so the hdf5_2x.dox line is correct and the sw_changes_2.x.dox line is wrong — it should read 2.1.1 (and the download URL should match whatever the actual ABI tarball was diffed against).

[bmribler]

The reason for the 2.1.0/2.1.1 mess was we did not change all the 2.1.0 occurrences to 2.1.1 when the 2.1.1 was released. There was some complication. We'll work it out.