Release Process

Release Process

How Jellyx releases are tagged, built, and published. This is the operational checklist for cutting a release.

Golden rule

Whenever a new release tag is created, the wiki MUST be updated in the same release work unit, before the release is considered done. This is non-optional. See Wiki Maintenance.

Versioning

• SemVer with prerelease suffixes (e.g. 0.3.2, 0.4.0-alpha.1).
• Tag format: v{VERSION} (e.g. v0.3.2).
• Release title format: Jellyx {VERSION} (e.g. Jellyx 0.3.2).

Version files to synchronize

The version string must be identical across three files before tagging:

File	Field
jellyx-desktop/Cargo.toml	version
jellyx-desktop/tauri.conf.json	version
ui/package.json	version

Known bug (v0.3.2): At the v0.3.2 tag these three files still report 0.3.1. The GitHub release/tag is 0.3.2, but in-app About may show 0.3.1. Future releases must bump all three files. See Release History.

Conventional commits

• Required. Release notes are generated from conventional commits between tags.
• scripts/generate-release-body.sh reads the commit log to build the release body.

CI

Workflow	Trigger	Builds
release.yml	v* tags	Linux + Windows
macos-dmg.yml	(macOS path)	macOS DMG

macOS is handled separately because of signing/notarization constraints in alpha.

Release checklist

1. Prepare

• All merged work for this release is on the default branch.
• Conventional commits are used for all changes since the last tag.
• Decide the next version per SemVer.

2. Bump versions (all three files)

• jellyx-desktop/Cargo.toml → version = "X.Y.Z"
• jellyx-desktop/tauri.conf.json → version: "X.Y.Z"
• ui/package.json → version: "X.Y.Z"
• All three match exactly.
• cargo build --workspace passes.

3. Tag

• git tag vX.Y.Z
• git push origin vX.Y.Z
• Tag triggers release.yml (Linux + Windows).
• macOS DMG workflow runs (if applicable).

4. Release body

• Run scripts/generate-release-body.sh to build notes from conventional commits.
• Create/edit the GitHub Release:
  • Title: Jellyx X.Y.Z
  • Body: generated notes
  • Assets: uploaded by CI

5. Validate

• Run scripts/validate-release.sh with the required arguments to check the release title and assets, e.g.:

./scripts/validate-release.sh vX.Y.Z "Jellyx X.Y.Z" Jellyx_X.Y.Z_amd64.deb Jellyx_X.Y.Z_amd64.rpm Jellyx-X.Y.Z.AppImage Jellyx-X.Y.Z.tar.gz JellyxSetup_X.Y.Z_x64.exe Jellyx-X.Y.Z.msi Jellyx-X.Y.Z_portable.exe Jellyx_aarch64.dmg

The CI job (release.yml / macos-dmg.yml) supplies the expected asset list; pass the same assets the release uploaded.

• Confirm all expected assets are present per Platform Support.

6. Update the wiki (MANDATORY, same work unit)

• Update Release History with the new version, date, and notes.
• Update Installation / Platform Support if artifacts changed.
• Update Features / User Guide if user-facing behavior changed.
• Update Architecture / UI Design / Packaging Guide if internals changed.
• Add a Known note if any version-sync issue exists (like v0.3.2).
• Commit and push the wiki before declaring the release done.

Known issue to remember

The v0.3.2 release shipped with the tag v0.3.2 but the three version files reporting 0.3.1. Document this transparently in Release History and on Installation → About note. Do not hide it.

Next step

• Packaging Guide — per-platform packaging details
• Wiki Maintenance — the recurring wiki-update procedure
• Release History — past releases