From c32b3cdece71734bb5a8c3ddb7605791507a0a67 Mon Sep 17 00:00:00 2001 From: Jonathan Rainville Date: Mon, 22 Jun 2026 13:40:50 -0400 Subject: [PATCH] docs(release): add post-release steps --- docs/internal/release-process.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/internal/release-process.md b/docs/internal/release-process.md index 70370488e7..4286bc8cff 100644 --- a/docs/internal/release-process.md +++ b/docs/internal/release-process.md @@ -67,6 +67,14 @@ This guide is meant to explain the flow and rules of the release process, i.e. t 2. It also lowers the amount of effort needed by devs, as no one needs to cherry-pick +## After the release process + +1. A release is considered done once the builds are published to the stores and on Github, plus the release branch is fully rebased on top of master. +2. A new tag **must** be created on the master branch's latest commit with the new version and the `-dev` suffix. eg: `2.39.0-dev` if `2.38.0` was just published. +3. The Status community's control node **should** be updated to the latest version. +4. The Status-Discord bridge **should** be updated to the latest version. +5. Blog posts and News Feed articles **should** be posted. + ## Frequently asked questions ### When is a release ready to be cut?