mirror of https://github.com/hanzoai/pack.git synced 2026-09-30 23:43:13 +00:00

Files

T

zeekayandHanzo Dev e12b42f3ec install: point install.sh at hanzoai/pack releases

REPO_OWNER/REPO_NAME built the GitHub API and download URLs from
railwayapp/railpack, so the installer could never find a release under
this fork -- hanzoai/pack has never had one.

REPO_NAME did double duty as both the repository slug (used in the API
and download URLs, needs to be "pack") and the installed command name
(used by `which`/`rm` on uninstall, needs to stay "railpack", the actual
compiled binary name per .goreleaser.yml). Collapsing both into "pack"
would make uninstall run `which pack`, which on many machines resolves to
the unrelated Cloud Native Buildpacks CLI. Split it into REPO_NAME (repo
slug and archive-name prefix, matching the project_name pinned in
.goreleaser.yml) and a new BINARY_NAME (the installed executable), and
routed each use to the right one.

RELEASE.md's GHCR links and package-registry URLs updated to match.

Do not merge until hanzoai/pack has an actual release: push a v* tag once
the prior two commits are on main and the release workflow has published
the builder, runtime, and frontend images. Before that, the download URL
this script builds 404s by construction.

Co-authored-by: Hanzo Dev <[email protected]>

2026-09-04 03:57:43 -07:00

2.1 KiB

Raw Permalink Blame History

Release Process

This document outlines the process for creating new releases of Hanzo Pack.

Creating a New Release

Determine the new version number following Semantic Versioning principles:
- MAJOR version for incompatible API changes
- MINOR version for backwards-compatible functionality additions
- PATCH version for backwards-compatible bug fixes

Create and push a new tag with the version number:

git fetch origin # or upstream, if you aren't using a fork
git tag v1.2.3 origin/main  # Replace with your version number
git push origin v1.2.3

The release workflow will automatically:
- Build and publish the frontend Docker image to GHCR
- Create a GitHub release with changelog
- Build and attach binaries for multiple platforms

Rerunning a Failed Release

This should rarely occur. If you need to rerun a release workflow, on a newer commit:

git tag -d v0.18.0 && git push --delete origin v0.18.0 && git tag v0.18.0 origin/main && git push origin v0.18.0

Release Artifacts

Frontend Docker Image

The frontend Docker image is published to GitHub Container Registry (GHCR) with the following tags:

ghcr.io/hanzoai/pack-frontend:latest (on default branch)
ghcr.io/hanzoai/pack-frontend:v1.2.3 (specific version)
ghcr.io/hanzoai/pack-frontend:1.2 (minor version)

The image is built for both linux/amd64 and linux/arm64 platforms.

Binary Releases

The release workflow automatically builds and attaches binaries for multiple platforms to the GitHub release.

Verifying a Release

After pushing a tag:

Check the Actions tab to monitor the release workflow
Verify the GitHub release is created with the correct artifacts
Confirm the frontend Docker image is available in the package registry

2.1 KiB Raw Permalink Blame History