Skip to content

Release Process

Jump to bottom
BenJule edited this page May 31, 2026 · 2 revisions

Release Process

Overview

master ──► Nightly (daily 02:00 UTC) ──► Manual review ──► Release tag ──► Full release

Releases are triggered by pushing a version tag v<version>-dev to master. This starts cd-release.yml which builds all platform artifacts and deploys to all distribution channels.

Release Types

Type Tag Format Visibility Trigger
Nightly nightly-YYYYMMDD-<sha> Pre-release Automatic daily
Release Candidate v02.07.00.XX-rc Pre-release Manual
Production Release v02.07.00.XX-dev Release Manual tag push

Nightly Release (Automatic)

Nightlies run automatically every day at 02:00 UTC via cd-nightly.yml. No manual intervention required.

  • 14-day rolling history — older nightlies are automatically deleted
  • Self-hosted runner builds are continue-on-error: true — a runner going offline does not fail the nightly
  • Artifact names include the Ubuntu version and _selfhosted suffix

Production Release

Step 1 — Ensure master is ready

Verify no open blockers in the current milestone:

gh issue list --milestone "v02.07.00-dev" --state open

Check the latest Nightly is green:

gh run list --workflow=cd-nightly.yml --limit 3

Step 2 — Bump the Version

Edit version.inc:

# Check current version
grep 'SLIC3R_VERSION' version.inc

# Edit manually or use sed:
sed -i 's/set(SLIC3R_VERSION "[^"]*")/set(SLIC3R_VERSION "02.07.00.56")/' version.inc

# Commit (signed)
git add version.inc
git commit -S -m "chore: bump version to v02.07.00.56"
git push origin master

Note

Version format: MAJOR.MINOR.PATCH.BUILD — all parts zero-padded to two digits. The BUILD number increments monotonically within a PATCH.

Step 3 — Push the Release Tag

VERSION=$(grep 'set(SLIC3R_VERSION' version.inc | grep -oP '\d+\.\d+\.\d+\.\d+')
git tag "v${VERSION}-dev"
git push origin "v${VERSION}-dev"

This immediately triggers cd-release.yml.

Step 4 — Monitor the Build

gh run list --workflow=cd-release.yml --limit 3
gh run watch <run-id>

The release workflow runs for approximately 2–3 hours (macOS and Windows builds are the slowest).

Step 5 — Review and Publish

  1. Go to Releases
  2. Find the draft release created by the workflow
  3. Review the auto-generated release notes (powered by automation-release-notes.yml)
  4. Edit as needed and click Publish release

Post-publish, these deploy workflows trigger automatically:

  • cd-deploy-apt.yml — updates the APT repository
  • cd-deploy-aur.yml — updates the AUR PKGBUILD
  • cd-deploy-homebrew.yml — opens a PR on the Homebrew tap
  • cd-deploy-winget.yml — submits to the winget manifest repository
  • cd-deploy-flatpak.yml — builds and submits the Flatpak bundle

Release Candidate (Optional)

For larger changes, create a RC before the production release:

  1. Run cd-release-candidate.yml manually via Actions → Run workflow
  2. Share the RC artifacts for testing
  3. Address any issues found via PRs to master
  4. Proceed with Step 3–5 above when satisfied

Hotfix Release

For critical fixes that cannot wait for a nightly cycle:

git checkout master && git pull
git checkout -b fix/critical-crash

# ... make the fix ...

git commit -S -m "fix: ..."
git push origin fix/critical-crash
gh pr create ...

# After PR merges:
sed -i 's/02\.07\.00\.55/02.07.00.56/' version.inc
git add version.inc && git commit -S -m "chore: bump version to v02.07.00.56"
git push origin master
git tag v02.07.00.56-dev && git push origin v02.07.00.56-dev

Version Format

Stored in version.inc:

set(SLIC3R_VERSION "02.07.00.55")
Component Meaning Example
MAJOR Upstream major version 02
MINOR Upstream minor version 07
PATCH Upstream patch version 00
BUILD Fork build increment 55

The -dev tag suffix marks this as a development/fork release (not to be confused with upstream's versioning).

Deployment Secrets

Required repository secrets for deploy workflows:

Secret Used by Purpose
AUR_SSH_PRIVATE_KEY cd-deploy-aur.yml SSH key for AUR git push
HOMEBREW_TAP_TOKEN cd-deploy-homebrew.yml GitHub PAT for tap repo PR
WINGET_TOKEN cd-deploy-winget.yml GitHub PAT for winget PR
S3 credentials cd-deploy-apt.yml Access to apt.s3-dev.ovh

Rollback

If a bad release is published:

  1. Go to Releases and edit the release
  2. Check This is a pre-release to demote it from the latest release slot
  3. Fix the issue via a hotfix PR
  4. Cut a new patch release (bump BUILD number)

Do not delete published releases — users may have already downloaded them and distribution channels may have already picked them up.

Clone this wiki locally