Reviews and quality

Release notes for engineers and for everyone else

Capture a release from your repositories, read its technical and business notes written from the same facts, have a reviewer approve them, publish them, and let people follow the channels they care about.

Deliver (Releases).

Channels

A channel belongs to a project. It names the repositories it covers and the branches or tags it follows, for example every tag starting with v. When a match is found, it only creates a draft: nothing is published or sent until people decide. An admin creates channels and can name who reviews and who publishes.

A release

Capture now (or a matching tag) asks your runner to record each repository's exact revision and the commits since the channel's last approved release. Each release shows:

• Revisions: one row per repository, with what it was compared with. "First release" when there is nothing before it.
• Gaps: what is incomplete, for example a tag that moved after an earlier capture, or a very long history.
• Availability: what was recorded. In the code only means no deployment has been recorded yet. Available in production appears only once a production deployment was verified AND who can use it was recorded (Deliver › a release candidate › Evidence › Availability). A deployment alone is never "available".

Two editions

• Technical notes list the changes with their evidence: revisions, migrations, tests as they really ran, and deployments. Security fixes show no detail until the release manager decides to disclose them.
• Business notes contain only what a person wrote for business readers. Under Choose what business readers see, write one plain sentence for each change that matters to them. A breaking change for business readers must be described before the release can be approved.

Review and publish

A reviewer of the channel approves both editions together. When the channel separates authors and reviewers (the default), someone who asked for the release or edited its wording cannot approve it. Any change after approval needs a new approval.

The release manager (or an admin) publishes. Publishing puts the notes in the release center and tells followers. Nothing is pushed to your repository host, and no tag is created or moved.

A published edition can be corrected: a new version with a note, approved by someone else. It can also be withdrawn, with a reason. E-mails already received cannot be recalled.

Following

On Following, choose business or technical notes and follow a channel. Following never changes your plan. You can pause or stop at any time, receive notices in the app or by e-mail, and choose a daily or weekly digest instead.

Evidence

Build evidence pack (release managers and auditors) exports an approved release: revisions, hierarchy, tests, approvals, deployments, gaps and the published notes, with a checksum for every file. Verify it with python -m src.release verify <folder>. It supports an audit. It is not a certification, and it carries no signature.