big-release
Go Node Python PHP
This repo ↗
bigbase canary · Go

This page is live on v0.4.0.
big-release set that number.

A real Go service, versioned and shipped by big-release on every merge to main. The version on the right isn't a screenshot — it's this app reading its own VERSION file, right now.

Add it to your Go project See the 3 files ↓
go.bigbase.click
LIVE · deploy passing
v0.4.0
served live from this app's VERSION file
▲ version computed & released by big-release — no human typed it
How this version happened

One merge, three automatic moves

big-release runs in CI after tests pass. It reads your commits, decides the next version, and ships it — no manual tagging, no changelog edits.

1

A conventional commit lands

Someone merges feat: add /healthz endpoint to main. That prefix is the only versioning input.

→
2

big-release computes the bump

feat means a minor bump. It reads the last git tag and calculates the next semantic version automatically.

→
3

It tags, releases & deploys

Pushes the git tag, creates the GitHub Release with notes, bumps VERSION — and this page redeploys.

The three files that did it

Copy these into your repo. That's the setup.

Straight from this canary — nothing hidden, nothing generated on the fly.

.big-release.yml release config 
# big-release configuration
tagFormat: "v${version}"
initialVersion: "0.1.0"

plugins:
  - changelog
  - git
  - github
.github/workflows/test-build-release.yml CI 
release:
  if: github.ref == 'refs/heads/main' && github.event_name == 'push'
  needs: [build]
  permissions: { contents: write }
  steps:
    - uses: actions/checkout@v7
      with: { fetch-depth: 0 }

    - name: Install big-release
      run: |
        curl -sL https://github.com/danielvm-git/big-release/releases/latest/download/big-release-linux-amd64 -o big-release
        chmod +x big-release && sudo mv big-release /usr/local/bin/

    - name: Run big-release
      run: big-release release --verbose
      env: { GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}" }
go.mod module 
module github.com/danielvm-git/bigbase-canary-go

go 1.22
Add it to your Go project

From zero to automated releases in four steps

No Node, no npm install, no plugins to wire. One static binary in CI.

terminal local test 
# preview the next release without publishing
big-release --dry-run
  1. 1

    Commit with a convention

    Use feat: / fix: prefixes. That's the whole contract.

  2. 2

    Drop in .big-release.yml

    Set tagFormat and pick your plugins. Copy the block on the left.

  3. 3

    Add the release job

    Install the binary, run big-release release after your tests.

  4. 4

    Merge to main

    big-release does the rest — tag, GitHub Release, changelog, deploy.

Why the version is what it is

Every bump is decided by a commit — not a human

big-release maps Conventional Commit types to semantic-version bumps. That's the entire rule set.

feat:→minor

A new feature bumps the middle digit — 0.3.1 → 0.4.0.

fix:→patch

A bug fix bumps the last digit — 0.3.1 → 0.3.2.

BREAKING CHANGE:→major

A breaking change bumps the first digit — 0.3.1 → 1.0.0.

See this canary's real release history on GitHub →