* Fix release-progress badges to read native issue-level Priority field
The Project Priority board field was consolidated into a Priority field
managed at the issue level (GitHub's org-wide custom issue fields), which
the GraphQL API mirrors into projects as ProjectV2ItemIssueFieldValue
instead of ProjectV2ItemFieldSingleSelectValue. The badge script's query
had no fragment for that type, so it silently found zero priority values
and would raise ProjectFieldMissingError on every run.
* Show TBD on the Next Release badge when no milestone due date is set
Previously the badge silently omitted any due-date annotation when the
milestone had none, which read as if the badge just hadn't picked one up.
* Update release-schedule image and plantuml source from add-next-release-badge branch
* Don't flag CODEOWNERS auto-assignment as a manual reviewer add on a PR's first pass
GitHub's own CODEOWNERS engine fires an identical review_requested webhook
(sender type User, not Bot) when it auto-assigns owners at PR-open time. If
one of those survives the cancel-in-progress race as the run that actually
executes, it was mistaken for a human deliberately requesting that reviewer,
permanently flagging them "manually added" and requiring separate approval —
e.g. a catch-all "*" owner also named on a touched area's CODEOWNERS line got
flagged on every PR touching that area, even though no human ever picked them.
Gate the manual-add detection and the sticky per-area assignment on
!isFirstCoordinationPass (no checklist comment posted yet), since that's
exactly the window where GitHub's own auto-assignment is indistinguishable
from a real human pick.
* Add Next Release badge and Medium/Low priority progress badges
Adds a "Next Release" badge (in-development version from H5public.h)
and extends the existing Critical/High priority progress badges with
Medium (P2) and Low (P3) priority tracking, all fed from the same
GitHub Project #39 gist-based badge pipeline.
* Remove in-progress 2.0 entry from release schedule diagram
The Release Schedule chart is meant to show only past releases that
have reached end of life; the in-development series is now tracked
separately by the Release Progress badges. Regenerate the PNG from
the updated PlantUML source and clarify the README wording.
* Add Latest Release badge and milestone target date to Next Release
Fetches the most recent published release in the current major
version series from the GitHub Releases API (e.g. "2.1.1
(2026-03-23)") and exposes it as a new "Latest Release" badge.
Also looks up the target due date of the matching GitHub milestone
(e.g. "HDF5 2.2.0") and appends it to the existing Next Release
badge when one is set. Both lookups are independent of the
project-board query and degrade gracefully to "N/A" on failure.
* 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
* 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
* 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.
FFM build requires Java 25, Jextract 25.
Generates FFM bindings during configure.
JNI is default when the requirements are not met or can be forced.
Presets added for maven and FFM - JNI is default selection.
Enhanced Maven options will work with either JNI or FFM
New Workflows for testing and maven uploads.
Extensive documentation changes for java.
This PR implements an automated release progress monitoring system for the HDF5 project. The changes add a dynamic badge to the README that tracks completion of release-blocking issues from GitHub Project #39, addressing issue #5742. The implementation consists of three components:
- Python script (update-progress.py) that uses GitHub's GraphQL API to query project items, filter for 'Release_Blocker' items, and calculate completion percentage
- GitHub Actions workflow (update-progress.yml) that runs the script every 24 hours, generates badge data, and publishes it via GitHub Gist
- README updates that remove tentative release language and add the new progress badge with color-coded status indicators
The system replaces static release information with real-time progress tracking, providing better transparency into HDF5's feature-driven release process. The badge displays progress percentages with green (90%+), yellow (60-79%), orange (40-59%), and red (<40%) color coding.
Removed mention of autotools removal, removed some other 2.0 is coming stuff. Updated the Help and support section to mention priority support and made some little text changes re the forum.
* Change URL for planned 2.0 features
* added forum link under help and support
The version number in the Autotools is scraped from README.md in configure.ac, which makes README.md count as 'code', which is a problem since changes to markdown files are ignored in CI.
This change scrapes the version number from H5public.h instead
of README.md.
This is where most people will expect to find license information. The
COPYING_LBNL_HDF5 file has also been renamed to LICENSE_LBNL_HDF5.
The licenses are unchanged.
Scot Breitenfeld
jhendersonHDF
Gerd Heber
Aleksandar Jelenak
bmribler
H. Joe Lee
Larry Knox
Allen Byrne
Lori Cooper
nbagha1
Dana Robinson