---
title: "Development Phases"
description: "How a change to Slint SC is made, reviewed, and merged."
---
Slint SC is developed in the same repository as Slint, [slint-ui/slint](https://github.com/slint-ui/slint), and follows the [same process as the rest of the repository](https://github.com/slint-ui/slint/blob/master/docs/internal/processes.md).
There is currently no Slint SC-specific tightening of this process.

## Branching

Organization members create branches usually named `<developer-name>/<feature-name>` in `slint-ui/slint`.
Outside contributors work from a fork and open a PR from there, since only organization members can push to `slint-ui/slint`.

`master` and `feature/*` branches are protected. Trusted members, which implicitly includes admins, can push directly to these branches.
For simple changes that don't need review and are unlikely to break CI, a push can push straight to `master` without a PR.

## Pull Requests and Review

A PR should be reviewed before merging, unless the change is trivial.
Reviewers leave comments; some are nitpicks, others must be addressed before merging, and reviewers indicate which is which.
There is no independent-reviewer requirement beyond ordinary review, and no distinction between safety-impacting and other changes at review time.

Once a PR is approved, the author merges it; auto-merge can be used once CI passes and approval is in. For external contributions, the reviewer merges instead.

Merges to `master` are squash or rebase only; GitHub is not configured to allow merge commits, so history stays linear.
A feature branch can be merged into `master` with a merge commit, but only by an admin.

## Continuous Integration

CI runs on every PR and a full CI runs three times a day on the latest `master` branch.
PRs that touch files relevant to Slint SC additionally run `scripts/slint_sc_test_suite.sh`, which exercises the Slint SC test suite and measures the runtime's coverage;
this is part of, not separate from, the full CI suite, which also runs on a fixed schedule three times a day independent of any single change.
What counts as "relevant" is currently determined by file path, though this is an imprecise proxy since the compiler is shared between Slint and Slint SC.

## Traceability

Every merged change is a commit in `master`'s history, identified by its hash, and stays there permanently.
Most commits are linked to their originating PR through GitHub's own linkage;
some additionally reference the issue they resolve via `Fixes #NNN` in the commit message.
Not every change is tied to a ticket: a PR number or commit hash is treated as sufficient for tracking on its own.

:::caution[TODO]
A release is planned to be cut from a dedicated branch, but the branching and freeze process for a release is not yet decided.
:::