Changelog

The Tuist Server and Kura images on GHCR now follow the same three-channel release train that the Tuist CLI has been on for a while. Instead of a single stable image cut on every merge, self-hosted operators can pick the channel that matches how close to the edge they want to run.

• ghcr.io/tuist/tuist:X.Y.0-canary.N is published on every merge to main that touches the server. Canaries are the bleeding edge, marked as GitHub prereleases, and never move :latest. Pin them explicitly if you want to track main.
• ghcr.io/tuist/tuist:X.Y.0-rc.N is published every Monday at 06:00 UTC from a releases/server-X.Y.x branch cut off main. Release candidates soak for a week; fixes ride onto the release branch as cherry-pick pull requests before the next -rc.(N+1) is cut.
• ghcr.io/tuist/tuist:X.Y.0 is the stable release, published the following Monday when the previous week's release candidate is promoted. Only stable releases move :latest, and only stable releases are picked up by mise or any other package manager that excludes prereleases by default.

Kura ships on exactly the same cadence: ghcr.io/tuist/kura:X.Y.0-canary.N, -rc.N, and stable move in lockstep with the server's train, and both trains fire on the same Monday morning as the CLI's promote job.

If you currently pin :latest, nothing changes for you today: :latest will keep tracking the newest stable, just on a weekly rhythm rather than a per-merge one. If you want the bleeding edge or a soaked candidate, the new tags are yours to pin.

You can now preserve source targets when using binary caching, giving you the flexibility to debug and inspect cached dependencies when needed.

Enable the Feature

Add this setting to your Tuist.swift configuration:

// Tuist.swift
import ProjectDescription

let tuist = Tuist(
  project: .tuist(
    cacheOptions: .options(
      keepSourceTargets: true
    )
  )
)

What You Get

When enabled, Tuist generates:

• Your regular workspace with cached binaries for fast builds
• An additional -Cached scheme containing all source targets isolated from the main dependency graph

This allows you to switch between optimized binary builds and full source access without regenerating your project.

Note: These source targets are for inspection and debugging only. If you modify their sources, you'll need to regenerate your project to reconcile the changes with the dependency graph.

We're excited to announce a major improvement to our release process: continuous releases for the Tuist CLI, Server, and macOS app. This change represents a key step in reducing the dependency of our contributors and users on the project maintainers.

What's Changed

Previously, releasing new versions of Tuist required manual intervention from maintainers. This created bottlenecks and delays in getting new features and fixes to users. Now, we've implemented an automated release pipeline that:

• Automatically detects releasable changes using git cliff{:target="_blank"}, a changelog generator that understands conventional commits
• Triggers releases on every push to main when there are meaningful changes to release
• Generates changelogs automatically based on commit messages, properly categorized and formatted
• Handles the entire release process including building, packaging, creating GitHub releases, and updating Homebrew formulas

How It Works

Each component (CLI, Server, and macOS app) now has its own release pipeline that:

1. Uses git cliff to analyze commits since the last release
2. Filters commits by scope (e.g., feat(cli): for CLI changes, feat(app): for app changes)
3. Determines if there are releasable changes by comparing with the current changelog
4. Automatically calculates the next version number
5. Builds and releases the component if changes are detected

Benefits for Contributors

• Faster feedback loop: Your contributions reach users as soon as they're merged
• No waiting for maintainers: Releases happen automatically when criteria are met
• Transparent process: The changelog clearly shows what changed in each release
• Better commit discipline: Encourages meaningful commit messages that translate to clear release notes

Benefits for Users

• More frequent updates: Get access to new features and fixes faster
• Predictable releases: Every meaningful change triggers a release
• Clear communication: Automatically generated changelogs show exactly what changed
• Stable releases: Only changes that pass all tests and checks are released

Technical Details

We're using git cliff with custom configurations for each component:

• CLI: Filters commits with (cli) scope or no scope
• Server: Filters commits with (server) scope
• App: Filters commits with (app) scope

The pipelines run on GitHub Actions and handle everything from version bumping to updating package managers like Homebrew.

This automation represents our commitment to making Tuist more accessible and reducing barriers for both contributors and users. We believe that great developer tools should be easy to contribute to and quick to deliver value.