Releasing

Releases are automated by .github/workflows/release.yml. Pushing a version tag builds the extension JAR and publishes a GitHub Release — no manual build or upload.

Tag scheme (CalVer)

Tags are dates: YYYY.MM.DD, e.g. 2026.05.25.

Situation	Tag example	Result
Normal release	2026.05.25	Published and marked latest
Second release the same day	2026.05.25.1	Published and marked latest
Pre-release / test build	2026.05.25-rc1	Published as pre-release, does not move "latest"

The rule the workflow uses: a hyphen anywhere in the tag makes it a pre-release; otherwise it becomes the latest release.

What a maintainer does

# 1. Make sure main is up to date and green (CI must pass).
git checkout main
git pull

# 2. Tag the commit you want to release with today's date.
git tag 2026.05.25

# 3. Push the tag. This is what triggers the release.
git push origin 2026.05.25

Within a minute or two the Release workflow runs and a new release appears on the Releases page with the JAR attached.

Prerequisites

• Write access to nccgroup/web3-decoder (to push tags). The workflow itself authenticates with the built-in GITHUB_TOKEN — no secrets to configure.
• The code must be on main. Tag-triggered workflows run the workflow file as it exists in the tagged commit, so release.yml and build.gradle must already be on the commit you tag. Always release from main.
• A clean, passing build — the CI workflow (build.yml) runs on every push/PR to help guarantee this.

How versioning works

You do not edit a version number in the source. The tag is the version:

You push	Manifest Implementation-Version	Versioned asset	Release title
2026.05.25	2026.05.25	web3-decoder-2026.05.25.jar	Web3 Decoder 2026.05.25

The workflow passes -PreleaseVersion=<tag> to Gradle, which records it in the JAR manifest. Local builds with no such property record version dev.

The JAR filename is intentionally constant (web3-decoder.jar) — see Local development — so CI produces a versioned copy for the release rather than relying on the filename to carry the version.

Release assets

Each release carries two copies of the same fat JAR:

• web3-decoder.jar — stable filename that powers the permanent "latest" URL:

  https://github.com/nccgroup/web3-decoder/releases/latest/download/web3-decoder.jar
  

• web3-decoder-<tag>.jar — version is visible on the Releases page / for archival.

Release notes are generated automatically from the merged PRs/commits since the previous tag (--generate-notes).

Local development

./gradlew jar always writes the JAR to a constant path:

web3-decoder/build/libs/web3-decoder.jar

The version never appears in the filename, so you can point Burp at this path once and rely on auto-reload across rebuilds. (Locally the manifest version is dev.)

Verifying a release

1. Open the Actions tab and confirm the Release run for your tag is green.
2. Check the new release has both JAR assets attached.
3. For a normal (non-hyphenated) release, confirm the latest URL serves it:

   curl -sIL https://github.com/nccgroup/web3-decoder/releases/latest/download/web3-decoder.jar | grep -i '^location\|^HTTP'
   

Fixing a bad release

Delete the release and its tag, fix the problem, then re-tag (use a same-day micro suffix):

gh release delete 2026.05.25 --cleanup-tag --yes   # removes release + the tag
# ...commit the fix to main...
git tag 2026.05.25.1 && git push origin 2026.05.25.1

Maintaining the workflow's pinned actions

The runner actions are pinned to commit SHAs (with the human-readable version in a trailing comment) to keep the supply chain locked down:

uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
uses: actions/setup-java@be666c2fcd27ec809703dec50e508c2fdc7f6654 # v5.2.0

When bumping these, resolve the new tag to its commit SHA and update both the SHA and the comment. Dependabot (github-actions ecosystem) can be added later to automate this if desired.