* Update Visual Studio versions in workflows
* Revert change to Windows ARM workflows
* Pin Intel OneAPI workflows to windows-2025
* Update more instances of issues
* review-checklist: show non-CODEOWNER reviewer when no owner is assigned
If the only assigned CODEOWNER is removed and a non-CODEOWNER is manually
added in their place, that person previously got no checklist mention and
their approval did not check the box.
For any area with no CODEOWNER in the requested set, fall back to
non-CODEOWNER reviewers (anyone assigned who is not an owner of any
touched area). They are shown in the mention and their approval counts
as sign-off for that area.
* review-checklist: update checklist on reviewer add/remove
Adding or removing a reviewer did not trigger a workflow run, leaving
the checklist comment stale until the next push.
Add review_requested and review_request_removed to the pull_request_target
activity types so the checklist updates immediately when a reviewer is
manually added or removed.
* review-checklist: show all requested owners per area in checklist
buildBody was using area.owners.find() — picking the first CODEOWNERS-listed
owner in the requested set. This broke reviewer swaps (removing @A and adding
@B would show @C, the next CODEOWNERS entry, not @B) and also failed to
reflect GitHub's CODEOWNERS auto-assignment, which requests all owners.
Switch to area.owners.filter() so every requested owner for an area is
mentioned in that row. Approval logic is unchanged: any owner approval
still checks the box.
* review-checklist: enforce one load-balanced reviewer per area
GitHub's CODEOWNERS auto-assignment requests all owners of touched files
when a PR opens, before the workflow runs. The script was then seeing them
already assigned and skipping its own selection entirely.
On opened/reopened: select one load-balanced reviewer per area (ignoring
GitHub's pre-assigned set), remove any auto-assigned CODEOWNERS not in the
selection, then add the chosen reviewer. Only code owners are removed —
manually-added non-owner reviewers are left untouched.
On synchronize: keep existing assignments (reviewer may have already started).
confirmedRequested now starts empty and is populated only with the script's
selection, so the checklist only mentions owners that were explicitly chosen.
* review-checklist: retry reviewer cleanup to handle GitHub auto-assign race
GitHub's CODEOWNERS auto-assignment can fire after the workflow starts,
re-adding extra reviewers after we remove them. Add a 15-second wait
followed by a second cleanup pass on opened/reopened events.
Extract the removal loop into enforceSelection() so both passes share
the same logic.
* zizmor: suppress template-injection for PR #6356 workflow files
Add zizmor_config.yml to ignore template-injection findings in the
setup-jextract action and maven/ctest workflow files introduced in
PR #6356, where inputs are caller-controlled but not user-controlled.
* review-checklist: don't re-assign reviewers on synchronize
On synchronize, chooseReviewers saw no owner assigned (because the
reviewer was manually removed) and re-added one via requestReviewers,
overriding the manual removal.
Reviewer assignment now only happens on opened/reopened. Synchronize
only updates the checklist display based on whoever is currently
assigned — manual removals are respected.
* zizmor: skip upload-sarif failure on fork PRs
* zizmor: move config out of workflows dir to fix GitHub Actions parse error
GitHub Actions parses all .yml files in .github/workflows/ as workflow
files; zizmor_config.yml there caused "unexpected value 'rules'" because
rules: is not valid workflow syntax. Moved to .github/zizmor.yml and
updated the --config path in zizmor.yml accordingly.
* review-checklist: retry on transient 401 from GitHub API
GitHub's API intermittently returns 401 on write operations
(issues.addAssignees, issues.createComment) even when the token has
Issues: write and PullRequests: write — read-only calls succeed in the
same run. The github-script action excludes 401 from retries by default.
Removing 401 from retry-exempt-status-codes and setting retries: 3
handles these transient failures with exponential backoff.
* review-checklist: fix checklist mention when non-requested owner approves
The mention in each checklist row was derived from the approver (if any),
so when a different area owner happened to approve first, the mention
changed from the assigned reviewer to the approver. Fix by decoupling
sign-off detection from display: signedOff now uses .some() so any
owner's approval checks the box, while the mention always shows the
confirmed-requested reviewer(s) via .filter(). Also shows multiple
reviewers when one is manually added alongside the load-balanced
selection.
* review-checklist: show approver name when signed off, requested reviewer(s) when pending
When an area is signed off, replace the mention with the approver so the
checklist shows who actually reviewed it (which may differ from whoever
was load-balanced as the requested reviewer). When pending, show all
confirmed-requested reviewers — the one load-balanced pick normally, but
two if a reviewer was manually added alongside it.
* zizmor: remove config file and --config flag
The ignored files (ctest.yml, maven-deploy.yml, maven-staging.yml,
setup-jextract/action.yml) had template-injection findings on
inputs.* references, which are not attacker-controllable. Rather than
suppressing them via a config file, let all findings surface in the
Security tab and address them individually if needed.
* CI: use pull_request_target so review-checklist runs on fork PRs
pull_request events from forks receive a read-only GITHUB_TOKEN and
are skipped by the job condition, so no checklist comment is posted
and no reviewers are assigned. Switching to pull_request_target fixes
this: GitHub always executes the workflow from the base repo
(HDFGroup/hdf5) with a full write token, regardless of whether the PR
comes from a fork. The fork's code is never checked out or executed.
The cross-repo guard (head.repo.full_name == github.repository) is
removed since it is no longer needed — pull_request_target only fires
for PRs targeting this repo's branches.
* CI: replace pull_request_target with safe two-workflow pattern for fork PRs
pull_request_target carries a GitHub security warning because it grants
write access to the privileged workflow at trigger time, which is risky
if the checkout is ever changed to use the fork's head ref.
Replace it with the recommended two-workflow pattern:
- review-checklist-gather.yml fires on pull_request (read-only, safe
for forks) and uploads the PR number as a short-lived artifact.
- review-checklist.yml fires on workflow_run when the gather job
completes, downloads the artifact for the PR number, then posts the
checklist comment and assigns reviewers with a full write token.
It never executes any code from the fork.
The script gains a prNumber parameter so the main workflow can supply
the PR number it read from the artifact; falls back to the event
payload for pull_request_review triggers.
* review-checklist: fix prAuthor crash and stale comment for workflow_run context
In the workflow_run path context.payload.pull_request is undefined, so
reading .user.login from it throws a TypeError. Use prData.user.login
instead — prData is already fetched from the API at step 5.
Also remove the stale comment saying fork PRs require pull_request_target;
they are now handled via the two-workflow pattern.
* CI: revert to pull_request_target, drop two-workflow pattern
The workflow_run approach adds a second hop before the checklist posts
and introduced a context.payload.pull_request crash in the gather path.
pull_request_target is simpler and equally safe here: GitHub always
executes the workflow from HDFGroup/hdf5:develop with a full write
token — the fork's code is never checked out or executed.
* CI: add zizmor workflow for GitHub Actions security analysis
zizmor is a static analyser that catches security issues specific to
GitHub Actions: pull_request_target misuse, expression injection,
unpinned action SHAs, and overly broad permissions.
Runs on push to develop and on PRs that touch .github/, uploads SARIF
to the Security tab (free for public repos via Advanced Security), and
annotates PR diffs inline with any findings.
* CI: run zizmor via pip instead of third-party action
Replace zizmorcore/zizmor-action (third-party) with a direct pip install
of zizmor==1.25.2. SARIF output is still uploaded to the Security tab via
github/codeql-action/upload-sarif (first-party). The only actions used
are from actions/ and github/, both trusted.
* CI: fix codeql-action pin to commit SHA (was tag object SHA)
* CI: add persist-credentials: false to review-checklist checkout
* CI: hash-pin zizmor pip install; suppress expected pull-request-target finding
- zizmor.yml: pin zizmor wheel to its SHA256 hash via --require-hashes so
the install is fully reproducible and passes zizmor's unpinned-tools audit
- review-checklist.yml: add zizmor: ignore[pull-request-target] comment so
zizmor does not flag its own host workflow; document why the usage is safe
* CI: update actions to Node.js 24 ahead of June 16 deprecation
- actions/checkout: v4.2.2 → v5.0.1 (node20 → node24)
- actions/github-script: v7.0.1 → v8.0.0 (node20 → node24)
- github/codeql-action: v3.36.2 → v4.36.2 (node20 → node24; v3 deprecated Dec 2026)
* CI: fix pip hash-pinning syntax — hash must be in requirements file
* CI: zizmor step continue-on-error so SARIF upload always runs
* review-checklist: skip pull_request_review on fork PRs (read-only token)
GitHub only grants a read-only GITHUB_TOKEN for pull_request_review events
when the PR originates from a fork, so the comment post fails with 403.
Restrict the review trigger to same-repo PRs; pull_request_target already
handles fork PRs for the open/sync/reopen case with a full write token.
* review-checklist: route reviews through workflow_run for fork PR support
pull_request_review grants only a read-only token for fork PRs, causing
a 403 when posting the checklist comment. Fix with a two-path design:
- pull_request_target handles open/sync/reopen for all PRs (full token,
immediate)
- A new gather workflow (review-checklist-gather.yml) fires on
pull_request_review, saves the PR number as an artifact, and exits.
The main workflow then fires via workflow_run with a full write token.
The script gains prNumber and isReview parameters. isReview suppresses
reviewer assignment (which only applies on open/sync/reopen). prAuthor
is sourced from prData.user.login since context.payload.pull_request is
not populated in the workflow_run context.
* review-checklist: simplify to pull_request_target only, drop gather workflow
pull_request_review triggers a fork workflow approval gate for first-time
contributors, which blocks every PR. There is no pull_request_review_target
equivalent in GitHub Actions.
Instead, rely on pull_request_target (opened/synchronize/reopened) only.
Approval boxes are still evaluated correctly: computeApprovals() re-reads
all existing reviews on every push, so boxes auto-check the next time the
author pushes after a reviewer approves.
Also restores the simpler script signature (no prNumber/isReview params)
and sources prAuthor from prData.user.login which works in all contexts.
* review-checklist: auto-check approval boxes on review via workflow_run
Add a minimal gather workflow (review-checklist-gather.yml) triggered by
pull_request_review that completes immediately with a read-only token. The
main workflow now also triggers via workflow_run on gather completion, giving
it the full write token it needs to update the checklist comment.
In workflow_run context, the script looks up the PR by head SHA (since
workflow_run.pull_requests is empty for fork PRs) and skips reviewer
assignment — only approval box state is updated.
Requires the repo "Fork pull request workflows from outside collaborators"
setting to be "Require approval for first-time contributors", which is
already the current setting.
---------
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
* Add per-area review checklist action and restructure CODEOWNERS
CODEOWNERS:
- Replace 11-person global catch-all with specific path rules per area,
assigning reviewers based on their actual strengths
- Global fallback is now @fortnern only for uncovered root files
- Remove @derobins, @epourmal, @qkoziol, @mkitti per team discussion
review-checklist GitHub Action (.github/workflows/review-checklist.yml):
- Posts a per-area sign-off checklist on every PR to develop (non-forks only)
- Reviewer lists and path patterns derived directly from CODEOWNERS
- Assigns ONE reviewer per area using fewest-open-PRs load balancing
- Complex changes (≥ 300 lines or any public/developer header modified)
always go to the first (senior) owner listed; routine changes are
load-balanced across all owners (500-line threshold for test/)
- Cohesion: reuses an already-assigned reviewer for related areas where
owner lists overlap, avoiding e.g. src/ and test/ going to different people
- Skips auto-assign if an area owner is already manually requested
- Checklist auto-checks when an owner approves; tracks latest review state
so a subsequent "request changes" unchecks the box
The previous regex only matched *public.h and *develop.h, missing hdf5.h
itself (the umbrella header), all VFD driver headers included by hdf5.h
(H5FDcore.h, H5FDmpio.h, H5FDsubfiling.h, etc.), and VOL connector headers
(H5VLconnector.h, H5VLnative.h, etc.). Changes to any of these now
correctly trigger senior-owner assignment.
* Added CMAKE_CFLAGS="-Mnovect" for the workflow with nvhpc 26.3.0 where the issue occurs instead of editing CMake code specifically for test/dt_arith.c that would be applied to all nvhpc versions.
Both ninja and curl are pre-installed on the GitHub macOS runners,
causing noisy "already installed" warnings. Drop those brew steps
entirely (or just remove ninja/curl where other packages like graphviz
or libaec are still needed).
feat: add optional digital signature verification for HDF5 filter plugins
Introduce an opt-in plugin signing and verification system that allows
HDF5 deployments to require cryptographically signed filter plugins before
loading them. Disabled by default (HDF5_REQUIRE_SIGNED_PLUGINS=OFF).
New tool: h5sign
- Signs plugin shared libraries by appending an RSA signature and a
14-byte footer (algo_id | sig_len | 8-byte magic | format_ver) to the
binary without modifying the original content.
- Supports SHA-512 (default), SHA-256, SHA-384, and their PSS variants
(-a/--algorithm flag).
- Detects already-signed plugins; --force strips the old signature and
re-signs.
- Security hardened: keeps the file descriptor open through hashing and
appending (no TOCTOU window), enforces a 2048-bit minimum RSA key size,
rolls back partial writes on failure, and rejects paths that are not
regular files.
Verification (H5PLsig.c)
- At plugin load time, reads the footer, validates the magic and format
version, then checks the RSA signature against all public keys found in
the KeyStore directory.
- File is hashed once; per-key verification operates on the pre-computed
digest (no redundant I/O for multi-key keystores).
- Plugins whose signature hash appears in revoked_signatures.txt are
rejected regardless of key validity.
- Runtime debug output via HDF5_DEBUG=pl.
KeyStore management
- Trusted public keys are PEM files in a directory specified by
HDF5_PLUGIN_KEYSTORE_DIR (build time) or HDF5_PLUGIN_KEYSTORE (env var).
- HDF5_LOCK_PLUGIN_KEYSTORE cmake option disables the env-var override for
security-hardened deployments.
Test infrastructure
- h5signverifytest: positive, negative, tamper, re-sign, and revocation
test cases.
- CTest fixture-based dependency graph (FIXTURES_SETUP/FIXTURES_REQUIRED)
replaces fragile DEPENDS chains so tests remain correct under -R filtering.
- Dedicated signed-plugins.yml CI workflow; full test suite scoped to
H5SIGN and H5PLUGIN-signature tests to avoid unrelated flaky failures.
- Cross-platform: Linux, macOS, and Windows (MSVC-compatible, BIO-based
OpenSSL I/O, HDsleep/HDsetenv portability wrappers).
Documentation: docs/PLUGIN_SIGNATURE_README.md covers usage, footer
format, revocation file format, FAQ, and troubleshooting.
Co-authored-by: Glenn Song <gsong@hdfgroup.org>
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* CI: remove EOL OS versions from workflows
- freebsd.yml: drop FreeBSD 13.5 (EOL Jan 2026); keep 14.3 and 15.0
- openbsd.yml: bump 7.5 → 7.8 (7.5 EOL ~Nov 2024); drop pinned gcc version
- i386.yml: replace Alpine 3.16 x86 (EOL May 2024) with i386/debian:bookworm (EOL Jun 2028)
* CI: install cmake from bookworm-backports for i386 workflow
* CI: fix OpenBSD workflow for 7.8
- Update vmactions/openbsd-vm v1.3.4 → v1.4.0 (supports 7.8)
- Drop GCC; use OpenBSD's built-in Clang (cc/c++) which is always in PATH
- Remove LD_LIBRARY_PATH workaround that was only needed for egcc
* CI: remove gmake from OpenBSD workflow
* Replace link in Glossary.dox with added Chessboard.svg file.
* Exclude checking links on server "web.cels.anl.gov" that rejects
automated link checker.
Restrict empty SARIF upload to pull_request events only, so that
push-to-develop (e.g. after merging a text-only PR) does not overwrite
the real CodeQL results in the Security tab with an empty SARIF.
* ci: add gate job to CodeQL workflow for text-only PRs
Remove paths-ignore from the workflow trigger and add a check-changes
job with dorny/paths-filter to detect code changes at the job level.
This ensures the workflow always triggers so the codeql-complete gate
job can report a passing status when analyze is skipped, preventing
text-only PRs from being blocked by required status checks.
* ci: check both check-changes and analyze results in gate job
Add check-changes to the needs array of codeql-complete so that a
failure in the change-detection job is not silently treated as a
skipped analysis.
* Consolidate documentation under doc/ directory
Move user-facing guides from release_docs/ and doxygen/ into a single
doc/ root. release_docs/ now holds only release artifacts (changelogs,
history, release process, maintainer info).
- git mv release_docs/INSTALL*.md, USING_*.md, README_HPC.md,
BuildSystemNotes.md, AutotoolsToCMakeOptions.md,
HDF5_Library_2.0.0_Migration_Guide.md → doc/
- git mv doxygen/ → doc/doxygen/
- Update CMakeLists.txt: HDF5_DOXYGEN_DIR and add_subdirectory path
- Update CMakeInstallation.cmake: all install paths for moved files
- Update bin/make_vers: hardcoded doxygen/ path substitution
- Update doc/doxygen/CMakeLists.txt: EXAMPLES_DIRECTORY and comments
- Update README.md, CONTRIBUTING.md, SECURITY.md, config/README.md,
release_docs/RELEASE_PROCESS.md: links to moved files
- Update doxygen .dox files: release_docs/ URLs for moved guides
- Rewrite release_docs/README.md for narrowed scope
* Add HDF5_DOCS_DIR variable for doc/ root path
Introduce HDF5_DOCS_DIR = \${HDF5_SOURCE_DIR}/doc so that
CMakeInstallation.cmake and future callers reference the doc/
directory symbolically rather than by hardcoded path.
HDF5_DOXYGEN_DIR is now derived from HDF5_DOCS_DIR.
* Updated SECURITY.md to meet OSSF Badge Standard
* Disable CodeQL on MD file changes
* Updated version support policy
* Suppress non-constant format string CodeQL alerts
Exclude cpp/non-constant-format and cpp/uncontrolled-format-string
rules. All flagged uses are intentional format-string-as-template
patterns for family file naming (%d) and configurable output
formatting (%g), not security vulnerabilities.
* Add justification comments for CodeQL exclusions
* Harden CI workflows: pin actions to SHAs and apply least-privilege permissions
- Pin all third-party actions to commit SHAs in codeql.yml and arm-main.yml
- Add top-level permissions: contents: read to codeql.yml and markdown-link-check.yml
- Move contents: write from top-level to job-level in daily-schedule.yml
* Exclude non-security CodeQL rules and tainted-format-string false positives
- Add cpp/tainted-format-string to exclusions (same justification as
existing format string rules: bounded snprintf with app-controlled formats)
- Exclude code style rules with no security severity: cpp/long-switch,
cpp/guarded-free, cpp/commented-out-code, cpp/use-of-goto
- These 350+ alerts are structural C patterns inherent to HDF5, not vulnerabilities
* Add OpenSSF Best Practices badge to README.md
* Add 2.1.0 CHANGELOG to HISTORY-2.X.md.
Set release default to draft.
* Updated CHANGELOG.md Executive Summary "Important" section similar to
that in HDF5 2.1.0 release.
* Re-write zlib/szip CMake logic for clarity
* Update external libaec, zlib-ng and zlib builds to not use patching process
* Add FindZLIBNG module to locate zlib-ng on system
* Rework HDF5 filter plugins support
* Update release progress badges to use Priority-based categorization
- Replace "Release Blockers"/"Release Must Do" with "Critical Priority"/"High Priority"
- Switch issue filtering from Release gating field to Priority field (P0 - Critical/P1 - High)
- Remove "Nice to Have" badge from workflow and README
- Add failure step: on workflow error, update both badge gist files to bright
purple (BF00FF) with "FAILURE" message
- Version auto-detected from src/H5public.h for milestone filtering
* Fix stale class docstring: release blocker -> priority issue
Refactor the cross-compilation infrastructure to rely on the standard
CMAKE_CROSSCOMPILING_EMULATOR variable instead of the custom
CROSSCOMPILING_PATH environment hack.
Key changes:
- Removed `ENVIRONMENT "${CROSSCOMPILING_PATH}"` from all test definitions.
- Updated custom commands (e.g., H5match_types, H5_gen) to invoke the
emulator explicitly when cross-compiling.
- Updated ConfigureChecks.cmake and HDF5UseFortran.cmake to enable
`try_run` checks when an emulator is defined.
- Added config/toolchain/mingw-w64-x86-64-wine.sh wrapper to automatically
locate MinGW runtime libraries (like libgfortran) for Wine execution.
- Cleaned up toolchain files to remove hardcoded emulator paths, deferring
configuration to the build environment.
Addresses the "multiple @ param documentation sections" warnings are caused by the interaction of three things:
1. MACRO_EXPANSION = YES with EXPAND_ONLY_PREDEF = NO in Doxyfile.in
2. Versioned API macros in H5version.h like:
\def documentation in APIVersions.dox like:
3. \def H5Tarray_create \api_vers_2{H5Tarray_create,H5Tarray_create1,H5Tarray_create2}
Because Doxygen expands all macros, it sees H5Tarray_create as an alias for H5Tarray_create1. It then associates documentation from both the \def block (for the macro) and the function's own doc block (with \param entries) with the same function — resulting in "multiple @ param documentation sections."
* Update Doxygen version from 1.16.0 to 1.16.1
Use Doxygen 1.16.1 for all platforms. This version includes the latest
bug fixes and improvements while maintaining compatibility with our
documentation format.
* Fix Windows Doxygen installation for version 1.16.1
Handle different Windows binary naming conventions across Doxygen versions:
- 1.16.1 uses: doxygen-VERSION.windows.x64.bin.zip
- 1.16.0 uses: doxygen-VERSION.x64.bin.zip
Try the newer naming convention first, then fall back to the older one
if the download fails. This ensures compatibility across versions.
* Use ssciwr/doxygen-install in setup-doxygen action
Replace direct installation of official Doxygen binaries with
ssciwr/doxygen-install action. This avoids Java documentation parsing
errors that occur with official binaries but not with distribution
builds.
The setup-doxygen action now serves as a thin wrapper around
ssciwr/doxygen-install@f13be16c83 (v1),
using commit hash for security and reproducibility.
* Remove redundant version specification from workflows
The setup-doxygen action already has a default version (1.16.1),
so explicit version specification in workflows is unnecessary.
This follows DRY principles and makes version updates simpler.
Ubuntu Clang tests had problems when using KyleMayes/install-llvm-action to install Clang 18.1 on Ubuntu 24.04, because the Clang that it installed needed libtinfo5 not present in the Ubuntu 24.04 image. However, Clang 18.1.3 is part of the Ubuntu 24.04 image and is used when CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are set to "clang" and "clang++".
Update CI workflows to use symbolic links instead of copying files to re-enable GitHub daily tests.
Workflows:
Update analysis.yml, cygwin.yml, and par-script.yml to use symbolic links instead of copying CTestScript.cmake and HDF5config.cmake.
Update par-source.yml and script.yml similarly to use symbolic links for the same files.
Commands:
Replace cp with ln -s in Linux workflows.
Replace Copy-Item with New-Item -ItemType SymbolicLink in Windows workflows.
Purpose:
Re-enable GitHub daily tests: linked HDF5config.cmake allows CMake to find the HDF5VersionParsing.cmake file to get the HDF5 version.
Also updated runs-on: ubuntu-22.04 to ubuntu-latest.
Scope Safety: Refactored parse_hdf5_version from a Macro to a Function to prevent variable namespace pollution.
Implemented a helper macro (_parse_version_component) to handle repetitive regex logic, significantly reducing code size and complexity.
Updated HDF5config.cmake to calculate paths dynamically using REALPATH relative to CMAKE_CURRENT_LIST_FILE, fixing issues with symlinks and execution context.
Decoupled the parsing logic from scope promotion; the helper now parses to a local variable, and the function explicitly handles the PARENT_SCOPE assignment.
* Fix Release Progress badges and workflow
- Fix update-progress.py to output blocker/mustdo counts in correct format
The workflow expects blocker_done=, blocker_total=, mustdo_done=, mustdo_total=
output lines but the script was only outputting human-readable format
- Update README badge links to point to project view 24 instead of base project
This fixes the workflow failures where BLOCKER_DONE and the related environment
variables were not being set, causing badge updates to fail.
The badges were pointing to old unmaintained gists under user X.
Updated to use the gist automatically maintained by the Release Progress
workflow (gist ID: 0ad2eabb63b28eb90d69f5e5b2c1496f).
The workflow now successfully updates these badges every 4 hours with
current release blocker and must-do progress.
The script now auto-detects the HDF5 version from src/H5public.h and
filters release blockers/must-do items by milestone matching that version.
Changes:
- Added get_hdf5_version_from_header() to read version from H5public.h
- Updated GraphQL query to fetch milestone information from issues
- Added milestone filtering logic to only count items for the target release
- Made validation more lenient when using milestone filter (allows 0/0)
- Added MILESTONE_FILTER environment variable for manual override
For develop branch with version 2.1.0 in H5public.h, this will now only
count items with milestone containing "2.1" (e.g., "2.1.0", "HDF5 2.1").
* Add version number to badge labels
The badges now display the version (e.g., "2.1 Release Blockers" instead
of just "Release Blockers") when filtering by milestone.
Changes:
- Python script outputs version to GitHub Actions
- Workflow passes version to badge generation script
- Badge script includes version in label if available
- Labels show "X.Y Release Blockers" / "X.Y Release Must Do"
The three badges now track:
1. Release Blockers - Critical issues that must be resolved
2. Release Must Do - Important items for the release
3. Release Nice to Have - Optional improvements for the release
All three badges show version prefix (e.g., "2.1") and support 0/0
display when no items exist for a milestone.
---------
Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
- Fix update-progress.py to output blocker/mustdo counts in correct format
The workflow expects blocker_done=, blocker_total=, mustdo_done=, mustdo_total=
output lines but the script was only outputting human-readable format
- Update README badge links to point to project view 24 instead of base project
This fixes the workflow failures where BLOCKER_DONE and related environment
variables were not being set, causing badge updates to fail.
Update version to 2.1 and derive version information from H5public.h, removing h5vers script and updating CMake and Java configurations.
Versioning:
Update version to 2.1 in H5public.h.
Derive version strings in H5public.h using macros.
CMake:
Extract version from H5public.h in HDF5config.cmake and HDF5AsSubdirMacros.cmake.
Configure README.md and CHANGELOG.md using CMakeLists.txt.
Java:
Generate H5Version.java from H5public.h for version consistency.
Update H5.java to use H5Version for version constants.
Removals:
Delete bin/h5vers script, previously used for version management.
jhendersonHDF
Scot Breitenfeld
dependabot[bot]
Larry Knox
phfix
Harish RS
Julien Schueller
