Releases

Listsome uses release-plz for automated releases. This ensures version consistency between Cargo.toml, git tags, CHANGELOG.md, and GitHub/Gitea releases.

Release Workflow

1. Push to main → Release PR workflow creates a PR with version bump and changelog update
2. Review and merge PR → release-plz release creates git tag and Codeberg release
3. Tag pushed → CI builds and uploads binaries to the release

Files Involved

• .woodpecker/release.yml - Woodpecker CI pipeline for releases
• .woodpecker/release-plz.toml - release-plz configuration
• CHANGELOG.md - Maintains full release history

Configuration

The release workflow is configured for git-only mode (no crates.io publishing):

[workspace]
git_only = true           # Don't publish to crates.io
publish = false           # Disable cargo publish
git_release_enable = true # Create Codeberg releases
semver_check = false     # Not a library
changelog_update = true  # Keep CHANGELOG.md updated

Tokens Required

The release_api_token secret must be configured in Woodpecker CI with appropriate permissions.

Creating a Token on Codeberg

1. Go to Settings → Applications on Codeberg
2. Click Create Token
3. Set a descriptive name (e.g., Woodpecker CI - listsome)
4. Select these scopes:
   • read:repository - Read repository data
   • write:repository - Push tags and create releases
5. Click Create Token
6. Copy the token immediately - it won’t be shown again

Configuring the Secret in Woodpecker CI

1. Go to your repository in Woodpecker CI
2. Navigate to Settings → Secrets
3. Create a new secret:
   • Name: release_api_token
   • Name: ssh_key (for Pages deployment in docs.yml)
   • Value: Paste the token from Codeberg (no quotes, no trailing newline)
4. Ensure the secret is available for:
   • tag event (for release and upload-assets steps)
   • push event (for release-pr step)
   • Image: rustlang/rust:* (or leave empty for all images)

Token Format Requirements

• Token must be a raw string with no extra whitespace
• When pasting into Woodpecker, ensure no trailing newline is added
• If you see “invalid header field value” errors, regenerate the token

CHANGELOG Management

The existing CHANGELOG.md is preserved and updated with each release:

• New commits are added to the [Unreleased] section
• When a release is created, unreleased changes are moved to the version section
• Full changelog history is maintained in the root CHANGELOG.md

Binaries

Each release includes pre-built binaries for multiple platforms:

• x86_64-unknown-linux-gnu - Standard Linux (glibc)
• x86_64-unknown-linux-musl - Static binary (works anywhere)
• aarch64-unknown-linux-gnu - ARM64 (Raspberry Pi, ARM servers)

Version Bumping

Versions are bumped automatically based on conventional commits:

• feat: commits → Minor version bump
• fix: commits → Patch version bump
• feat!: or fix!: commits → Major version bump
• Other commits → Patch version bump

See Conventional Commits for details.

Manual Release (Emergency)

If automated release fails, you can create a release manually:

# Install release-plz
cargo install release-plz

# Bump version and update changelog locally
release-plz update

# Create the release
release-plz release --forge gitea

See Also

• release-plz Documentation
• Conventional Commits
• Keep a Changelog