Project Release Process

This document defines the process for versioning and distributing the sized project independently of the Git hosting provider (GitHub, GitLab, Gitea).

1. Versioning and Tagging

The project adheres to Semantic Versioning.

Synchronize the version in Cargo.toml.
Update CHANGELOG.md with the release notes.
Commit and create a git tag:
```
git tag -a v1.0.0 -m "Release v1.0.0"
```

2. Asset Generation

The scripts/release.sh script is the authoritative way to generate release assets locally or in any CI environment.

./scripts/release.sh

This script generates:

Optimized Binary: The production-ready sized executable.
Documentation: The sized.1 man page.
Shell Completions: Scripts for Bash, Zsh, and Fish.
System Installers: A .deb package for Debian-based Linux distributions.

All assets are gathered in the dist/v<VERSION>/ directory.

3. Distribution Channels

crates.io

To update the project on the central Rust registry:

cargo publish

System Package Managers

For Homebrew, GitLab, or Gitea-based distribution:

Push the git tag to your SCM.
Run the release script to generate assets.
Attach the contents of the dist/ folder to your SCM's "Release" or "Tag" entry.
Update downstream formulas (like homebrew-tap) with the new source URL and SHA256 of the generated tarball.

4. Automation & Hooks

To automate asset generation locally, you can use a git post-checkout or a wrapper script. Since gitea and gitlab use different CI formats, it is recommended to simply call ./scripts/release.sh within your preferred CI runner (e.g., gitlab-ci.yml or gitea-actions).

5. Manual Installation

For system-wide installation from source, use the Makefile:

make install

Defaults to PREFIX=/usr/local. Overridable via PREFIX=/your/path make install.

1.9 KiB Raw Blame History