Releases and versions

Release data is generated when the site is built (npm run build:site); this copy was not built, so the tables are empty. See aveproject/ave releases.

Catalog release or schema version

A catalog release is a fixed, checksummed copy of the whole record set, tagged vX.Y.Z and never changed once published. A schema version describes the shape of a single record; each record names its own schema_version, and the two numbers move independently.

Catalog releases

A release with all three files (ave-records.json, ave-records.manifest.json, SHA256SUMS) and a provenance attestation can be pinned and verified; releases before v1.2.0 predate those files.

Schema versions

Versioned schema files and these record sets are frozen: they never change once published, not even for a typo. The field reference always shows the newest schema.

Pin and verify a release

Run these on a machine with network access. They need curl, git, Python 3.8 or later and, for the last step, the GitHub CLI signed in to any account. The tag is filled in with the newest release that can be pinned.

1. Download the three files of a release into a directory named after its tag.

   TAG=v1.2.0 mkdir -p "ave-$TAG" for f in ave-records.json ave-records.manifest.json SHA256SUMS; do curl -fsSL -o "ave-$TAG/$f" "https://github.com/aveproject/ave/releases/download/$TAG/$f" done

2. Check the checksums. This catches a damaged download, not a forged release.

   (cd "ave-$TAG" && sha256sum -c SHA256SUMS)

3. Check the files against each other and the tag: the manifest describes the records file, and source_commit is the commit the tag points at.

   git -c advice.detachedHead=false clone -q --depth 1 --branch "$TAG" https://github.com/aveproject/ave ave-src python3 ave-src/scripts/check_release_assets.py "ave-$TAG" --tag "$TAG" --git-dir ave-src

4. Check provenance: both files were built by the release workflow in aveproject/ave. This is the check that does not trust where you downloaded from.

   for f in ave-records.json ave-records.manifest.json; do gh attestation verify "ave-$TAG/$f" --repo aveproject/ave \ --signer-workflow aveproject/ave/.github/workflows/catalog-release.yml done

If any check fails, do not use the files: download them again, and keep using the release you had. The implementer guide explains each check and shows how to verify the files again each time your tool starts.

Use a release offline

Stage the release on a connected host and run the checks above there, carry the three files across, run sha256sum -c SHA256SUMS again on the offline host, and point your tool at that directory. Refresh on a stated cadence and never fetch at scan time. The guide's air-gapped section has the full procedure, and the reference API can serve a pinned release too (?release=vX.Y.Z).

Two files named ave-records-v1.1.0.json

The v1.1.0 GitHub release (2026-06-24) shipped one asset, ave-records-v1.1.0.json: 51 records on schema 1.0.0. The repository's dist/ave-records-v1.1.0.json, added later (2026-07-19), holds 59 records on schema 1.1.0. They are different files with the same name: the first is named after a catalog release, the second after a schema version. v1.2.0 is the first release with the three files above, and the first whose record set can be checked end to end.