mirror of
https://github.com/lexmount/moli.git
synced 2026-10-03 16:00:45 +00:00
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
# Releasing Moli
|
|
|
|
The release workflow builds and publishes four native archives:
|
|
|
|
| System | Rust target | Archive |
|
|
| --- | --- | --- |
|
|
| Linux x86_64 | `x86_64-unknown-linux-gnu` | `.tar.gz` |
|
|
| macOS Intel | `x86_64-apple-darwin` | `.tar.gz` |
|
|
| macOS Apple Silicon | `aarch64-apple-darwin` | `.tar.gz` |
|
|
| Windows x86_64 | `x86_64-pc-windows-msvc` | `.zip` |
|
|
|
|
Every archive contains the `moli` executable, project licenses, README,
|
|
version marker, and third-party license notices. GitHub displays the SHA-256
|
|
digest for each uploaded release asset.
|
|
|
|
Each artifact is built on its native GitHub-hosted runner. The packager strips
|
|
only a staging copy, leaving the binary under `target/release` unchanged for
|
|
debugging. Because stripping invalidates a Mach-O signature, macOS staging
|
|
binaries are ad-hoc signed again and verified before packaging. They are not
|
|
Developer ID signed or notarized. Windows executables are not Authenticode
|
|
signed. The Windows build disables the default `jemalloc` feature and uses the
|
|
system allocator because upstream treats the Windows/MSVC combination as
|
|
untested.
|
|
|
|
## Prepare the release
|
|
|
|
1. Update `version` in `moli/Cargo.toml` and refresh `Cargo.lock`.
|
|
2. Commit and push those changes to the ref that should be released.
|
|
3. Optionally build the package for your current operating system locally.
|
|
|
|
Linux or macOS:
|
|
|
|
```bash
|
|
scripts/release.sh --version 0.1.1
|
|
```
|
|
|
|
Windows PowerShell:
|
|
|
|
```powershell
|
|
python scripts/release.py --version 0.1.1 --no-default-features
|
|
```
|
|
|
|
Artifacts are written to `dist/`. The packager rejects a version that does
|
|
not match `moli/Cargo.toml`, checks the native Rust target, strips the staged
|
|
executable, and verifies the packaged binary's reported version.
|
|
|
|
## Trigger GitHub Release
|
|
|
|
1. Open **Actions** in GitHub and choose the **Release** workflow.
|
|
2. Select **Run workflow** and choose the Git ref containing the release.
|
|
3. Enter the version (with or without a leading `v`).
|
|
4. Choose whether the release should be a prerelease or a draft, then run it.
|
|
|
|
The workflow validates the selected commit, builds all four native artifacts
|
|
in parallel, verifies the expected archives, creates the corresponding
|
|
`vX.Y.Z` tag, generates release notes, and uploads all four archives. It stops
|
|
without creating a release if any platform fails, if the requested version does
|
|
not match the manifest, or if the tag already exists.
|