Updating a native jar requires at least two commits. The first commit updates a GitHub workflow that generates the native libraries using GitHub Actions; the second will update the *-native subproject build to use the new native libraries.

1. The native-compression/*-native subprojects depend on a .zip file and checksum file that contain the native libraries, which are hosted on Unidata servers. These files are generated on GitHub using the .github/worlflows/lib*.yml. To update a native jar, you first update the associated workflow. Once the workflow is on the main branch (currently maint-5.x), manually trigger the workflow on GitHub. The workflow output will provide a zip file and sha-256 checksum value.
2. Copy the zip file generated by the workflow in step 1 to the Unidata server and generate a checksum for the file. Update the native-compression/lib*-native/build.gradle.kts file with the new version information and checksum value from the GitHub output. If everything looks good, and the draft PR with these changes passes, update the documentation to reflect the latest version of the native jar (see docs/src/site/_config.yml). Once these changes are merged, the final step is to publish a new native jar.

The native jars are versioned based on the native library version (plus a build number). These jars are also published separate to the rest of the project jars. To publish a native jar, you must set the unidata.native.publish=true system property when running the Gradle publish command. For example, to publish the libblosc2-native jar, run:

./gradlew -D"unidata.native.publish=true" :libblosc2-native:publish