Files
pack/RELEASE.md
T
Michael BiancoandGitHub 38e31fcd66 test: benchmark gha job summaries (#484)
* build: docker client timeout doesn't do anything anymore

this has been deprecated for years

* Revert "test: correct benchmark workflow permissions (#480)"

This reverts commit d3b14c29ae.

* docs: comment on why py + pipx are needed for java

* test: increase ci timeouts

* test: attempt to add benchmark summary to gha job

* docs: note about rerunning a release
2026-03-12 12:04:00 -06:00

2.1 KiB

Release Process

This document outlines the process for creating new releases of Railpack.

Creating a New Release

  1. 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
  2. Create and push a new tag with the version number:

    git tag v1.2.3  # Replace with your version number
    git push origin --tags
    
  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/railpack/railpack-frontend:latest (on default branch)
  • ghcr.io/railpack/railpack-frontend:v1.2.3 (specific version)
  • ghcr.io/railpack/railpack-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:

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