Skip to content

Validate Apache Release

Note: this doc will be updated continuously. Use Java 17 to build and verify HugeGraph 1.8.0 release packages (the Maven build accepts only JDK 17); use Java 11 for 1.7.0. Since version 1.5.0, components other than the client no longer support Java 8.

Graduation note: Apache HugeGraph graduated in January 2026. Official release voting is now completed within the HugeGraph community (PMC binding votes on dev@hugegraph.apache.org), and no longer requires Incubator general@incubator.apache.org approval.

Automated release validation

The workflow and dist/validate-release.sh use the same Java 17 checks. Specify the package version and SVN RC path separately, and use the Maven staging repository from the vote email. The four Server/Toolchain source and binary archives are required. The same directory may also contain AI and Computer source archives. Every archive must include SHA512 and GPG signatures; unknown packages and mismatched versions are rejected. All present archives receive integrity, contents and license checks; Computer sources are also rebuilt with Maven. AI and Computer product runtime validation remains a separate task.

1bash dist/validate-release.sh --svn-path 1.8.0/RC1 \
2  --staging-repository https://repository.apache.org/content/repositories/<staging-id>/ 1.8.0 imbajin
3# Existing local-package interface is preserved:
4bash dist/validate-release.sh 1.8.0 imbajin /path/to/rc 17

Strict RC validation builds with fresh, separate Maven repositories and does not preinstall a local Server SDK. It validates both source-built and downloaded binaries through Server, Client, ordinary Loader, Tools and Hubble business assertions. Logs remain available after failures. The source-prevalidation workflow mode uses exact Server/Toolchain commit SHAs and unsigned archives; its result does not prove real RC signatures, downloads or remote staging dependency resolution. Review license-review-*.txt for license choices and exceptions; explicit Category-X-only dependencies block validation. Automatic success does not approve the release. The console and GitHub Job Summary show the result, failed phase, review notes and log location. Source prevalidation is clearly separate from RC acceptance. See the validator instructions for local prevalidation and evidence paths.

Verification

When the internal temporary release and packaging work is completed, other community developers ( especially PMC) need to participate in verification based on ASF release policy and checklist references:

  • ASF release policy
  • Incubator checklist (historical reference) To ensure the “correctness + completeness” of someone’s published version, here requires **everyone ** to participate as much as possible, and then explain which items you have checked in the subsequent email reply.(The following are the core items)

1. prepare

If there is no svn or gpg or wget environment locally, it is recommended to install it first (windows recommend using WSL2 environment, or at least git-bash), also make sure to install java (Java 17 for HugeGraph 1.8.0+, Java 11 for 1.7.0) and maven software (≥ 3.6.3)

 1# 1. install svn
 2# ubuntu/debian
 3sudo apt install subversion -y
 4# MacOS
 5brew install subversion
 6# To verify that the installation was successful, execute the following command:
 7svn --version
 8
 9# 2. install gpg
10# ubuntu/debian
11sudo apt-get install gnupg -y
12# MacOS
13brew install gnupg
14# To verify that the installation was successful, execute the following command:
15gpg --version
16
17# 3. install wget (we will enhance it later, like use `curl`)
18# ubuntu/debian
19sudo apt-get install wget -y
20# MacOS
21brew install wget
22
23# 4. Download the hugegraph-svn directory 
24# For version number, pay attention to fill in the verification version
25svn co https://dist.apache.org/repos/dist/dev/hugegraph/1.x.x/
26# (Note) If svn downloads a file very slowly, 
27# you can consider wget to download a single file, as follows (or consider using a proxy)
28wget https://dist.apache.org/repos/dist/dev/hugegraph/1.x.x/apache-hugegraph-toolchain-1.x.x.tar.gz

2. check hash value

First you need to check the file integrity of the source + binary package, Verify by shasum to ensure that it is consistent with the hash value published on apache/GitHub (Usually sha512), Here is the same as the last step of 0x02 inspection.

1execute the following command:
2for i in *.tar.gz; do echo $i; shasum -a 512 --check  $i.sha512; done

3. check gpg signature

This is to ensure that the published package is uploaded by a reliable person. Assuming tom signs and uploads, others should download A’s public key and then perform signature confirmation.

Related commands:

 1# 1. Download project trusted public key to local (required for the first time) & import
 2curl  https://downloads.apache.org/hugegraph/KEYS > KEYS
 3gpg --import KEYS
 4
 5# After importing, you can see the following output, which means that x user public keys have been imported
 6gpg: /home/ubuntu/.gnupg/trustdb.gpg: trustdb created
 7gpg: key BA7E78F8A81A885E: public key "imbajin (apache mail) <jin@apache.org>" imported
 8gpg: key 818108E7924549CC: public key "vaughn <vaughn@apache.org>" imported
 9gpg: key 28DCAED849C4180E: public key "coderzc (CODE SIGNING KEY) <zhaocong@apache.org>" imported
10...
11gpg: Total number processed: x
12gpg:               imported: x
13
14# 2. Compare the full primary-key fingerprint with the release vote email
15release_signer_fingerprint='<signer-full-fingerprint>'
16gpg --fingerprint -- "$release_signer_fingerprint"
17
18# 3. Use a subshell so verification failure does not exit your interactive terminal
19(
20  for archive in *.tar.gz; do
21    gpg --status-fd 1 --verify -- "$archive.asc" "$archive" > "$archive.status" || {
22      status=$?
23      printf 'Signature verification failed: %s\n' "$archive" >&2
24      cat "$archive.status"
25      exit "$status"
26    }
27    cat "$archive.status"
28    if grep -Eq '^\[GNUPG:\] (REVKEYSIG|EXPKEYSIG|EXPSIG)( |$)' "$archive.status"; then
29      printf 'Expired or revoked signature: %s\n' "$archive" >&2
30      exit 1
31    fi
32    grep -q '^\[GNUPG:\] VALIDSIG ' "$archive.status" || {
33      printf 'Missing valid signature: %s\n' "$archive" >&2
34      exit 1
35    }
36  done
37)

Require exit code zero and a VALIDSIG fingerprint matching the vote signer. When a signing subkey is used, compare its reported primary-key fingerprint. A key-trust warning alone does not invalidate a signature; do not infer success from localized Good signature text. Stop on REVKEYSIG, EXPKEYSIG or EXPSIG, even alongside VALIDSIG or exit code zero; ask the release manager to review or update the candidate. See the GnuPG status format.

First confirm the overall integrity/consistency, and then confirm the specific content (key)

4. Check the archive contents

Check the contents of the archive downloaded from preparation work. Divided into two aspects: source code package + binary package, The source code package is stricter, it can be said that the core part (Because it is longer, For a complete list refer to the official Wiki)

A. source package

After decompressing *hugegraph*src.tar.gz, Do the following checks:

  1. package/folder naming should match the release line (historical releases may still contain incubating), and no empty files/folders
  2. LICENSE + NOTICE exist and the content is normal; DISCLAIMER is required for historical incubating artifacts
  3. does not exist binaries (without LICENSE)
  4. The source code files all contain the standard ASF License header (this could be done with the Maven-MAT plugin)
  5. Check whether the pom.xml version number of each parent/child module is consistent (and meet expectations)
  6. Finally, make sure the source code works/compiles correctly
1# prefer to use/switch to `java 17` for HugeGraph 1.8.0+ (`java 11` for 1.7.0) for the following operations (compiling/running) (Note: `Computer` only supports `java >= 11`)
2# java --version
3
4# try to compile in the Unix env to check if it works well (-P is optional)
5mvn -s /path/to/staging-settings.xml -Dmaven.repo.local=/path/to/fresh-m2 \
6  clean install -Papache-release -DskipTests -Dgpg.skip=true

The manual Maven command must use settings pointing to the staging repository from the vote email and a fresh local repository. Do not preinstall local Server SDK artifacts to hide missing staged dependencies. The automated validator configures these settings for you.

B. binary package

After decompressing xxx-hugegraph.tar.gz, perform the following checks:

  1. package/folder naming should match the release line (historical releases may still contain incubating)
  2. LICENSE and NOTICE file exists and the content is normal (DISCLAIMER applies to historical incubating artifacts)
  3. start server
 1# hugegraph-server
 2bin/start-hugegraph.sh
 3
 4# hugegraph-loader
 5bin/hugegraph-loader.sh -g hugegraph -f example/file/struct.json -s example/file/schema.groovy
 6
 7# hugegraph-hubble
 8bin/start-hubble.sh
 9
10more reference official website: https://hugegraph.apache.org/docs/quickstart

Note: If a third-party dependency is introduced in the binary package, you need to update the LICENSE and add the third-party dependent LICENSE; if the third-party dependent LICENSE is Apache 2.0, and the corresponding project contains NOTICE, you also need to update Our NOTICE file

5. Check the official website and GitHub and other pages

  1. Make sure that the official website at least meets apache website check, and no circular links, etc.
  2. Update download link and release notes updated
  3. …

Mail Template

After the check & test, you should reply to the mail with the following content: (normal devs & PMC)

1[] +1 approve
2
3[] +0 no opinion
4
5[] -1 disapprove with the reason
 1+1 (non-binding)
 2I checked:
 31. Download link/tag in mail are valid
 42. Checksum and GPG signatures are OK
 53. LICENSE & NOTICE exist
 64. Build successfully on XX OS & Version XX
 75. No unexpected binary files
 86. Date is right in the NOTICE file
 97. Compile from source is fine under JavaXX
108. No empty file & directory found
119. Test running XXX service OK
1210. ....

and the PMC members should reply with binding, it’s important for summary the valid votes:

 1+1 (binding)
 2I checked:
 31. Download link/tag in mail are valid
 42. Checksum and GPG signatures are OK
 53. LICENSE & NOTICE exist
 64. Build successfully on XX OS & Version XX
 75. No unexpected binary files
 86. Date is right in the NOTICE file
 97. Compile from source is fine under JavaXX
108. No empty file & directory found
119. Test running XX process OK
1210. ....