Skip to content

docs(release): adopt the release-stream process - #42

Open
piotr-roslaniec wants to merge 3 commits into
devfrom
docs/release-streams-process
Open

piotr-roslaniec wants to merge 3 commits into
devfrom
docs/release-streams-process

Conversation

@piotr-roslaniec

@piotr-roslaniec piotr-roslaniec commented Oct 15, 2026 •

Copy link
Copy Markdown

Summary

Adopt the release process used by the private keep-core-security repository as the
standard for this library: a release policy, the stream process, a release runbook, a PR
template and the required-answers check that enforces the template.

No runtime behavior changes. Every file here is policy, process, CI or docs. GitHub
settings (rulesets, required checks, labels, tag-creation restriction, Issues) are a
separate, later change that follows this PR. SECURITY.md now points to GitHub private
vulnerability reporting, matching the policy and the enabled setting.

Linked issues

Refs #37 (the parent PR for the current stream).

Breaking change

  • No - existing consumers and peers on the previous version still interoperate.
  • Yes, coordinated activation - all parties of a ceremony must switch together at an agreed point (for example a new mandatory session parameter).
  • Yes, cutover - protocol messages, proof transcripts or Fiat-Shamir challenges, session binding, or key-share or pre-parameter serialization change, so old and new parties cannot complete one ceremony. Public Go API breaks for the keep-core consumer also count.
  • Not applicable - CI, docs, tests or tooling only; no runtime effect on ceremonies.

Release stream

  • Next library release (dev into master)
  • Embargoed security fix (coordinate through private vulnerability reporting)
  • CI, docs or tests only

Security

  • Not security-related
  • Security fix - severity: , finding ID: , embargoed until:

Testing

  • actionlint .github/workflows/pr-description.yml - clean.
  • Extracted the new workflow's run: block and drove it directly: no ticks, one tick
    per section, two ticks in one section, a pre-adoption body with and without the
    <!-- pr-template: v1 --> marker, and a CRLF body. The four options of the
    "Breaking change" section and the two of the "Security" section were each run through
    the check; exactly one tick per section passes, anything else fails.
  • Ran release.yml's awk extraction against a scratch copy of CHANGELOG.md with the
    heading renamed to ## [1.4.0] - 2026-10-15: the section is non-empty and stops at the
    next ## [; with the heading left as [Unreleased] it is empty, which is why the
    workflow fails the run.
  • Checked every relative link in the added and changed markdown resolves to a file.

Rollback

Revert the commit. Nothing outside the repository depends on these files.

Checklist

  • No secrets, private keys or private endpoints in the code, logs or this description.
  • Title follows Conventional Commits (type(scope): description).
  • Docs and changelog updated where behavior changes.

Add the release policy, the stream process and the release runbook, plus the
PR template and the CI check that enforces it.

- docs/release-policy.md: compatibility classes R/P/A/X/T, the v1.x version
  rule, release count, approvals, security reporting and the current cycle.
- docs/release-streams.md: how a change is sorted into a stream, described in
  its PR, tracked in a parent PR and recorded in the changelog.
- docs/release-process.md: the steps to move `[Unreleased]` to a version
  heading, merge into master, tag and let release.yml publish.
- .github/pull_request_template.md and .github/workflows/pr-description.yml
  (job `required-answers`): require exactly one "Breaking change" answer and
  one "Security" answer per PR.
- .claude/skills/release-streams/SKILL.md: the agent workflow for the above.
- README: a Releases section linking the three documents.
- CHANGELOG: state the v1.x-only tag rule and drop the pre-release tag example
  (`go get @latest` would skip a pre-release and select the older v1.3.5).
Name piotr-roslaniec and lrsaturnino as release owners, require a non-author
approval for PRs into dev, note that only org admins create v* tags, and point
SECURITY.md at GitHub private vulnerability reporting instead of the upstream
bounty page.
…rding

A workflow re-run checks out the tagged commit, so it cannot pick up a later
CHANGELOG fix; say to edit the release body or cut the next patch. Describe tag
creation as a procedure rather than an enforced rule, and state the pre-release
ordering without claiming a resolution outcome.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant