From 12c6df83f505e866f98999b47897e06c0493a28a Mon Sep 17 00:00:00 2001 From: Nick Volynkin Date: Fri, 25 Apr 2025 15:09:31 +0300 Subject: [PATCH 1/2] [docs] Update release policy: Release Candidate versions Signed-off-by: Nick Volynkin --- docs/release.md | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/docs/release.md b/docs/release.md index 062b7a56..22366f6b 100644 --- a/docs/release.md +++ b/docs/release.md @@ -1,10 +1,37 @@ # Release Workflow -This section explains how Cozystack builds and releases are made. +This document describes Cozystack’s release process. + +## Introduction + +Cozystack uses a staged release process to ensure stability and flexibility during development. + +There are three types of releases: + +- **Release Candidates (RC)** – Preview versions (e.g., `v0.42.0-rc.1`) used for final testing and validation. +- **Regular Releases** – Final versions (e.g., `v0.42.0`) that are feature-complete and thoroughly tested. +- **Patch Releases** – Bugfix-only updates (e.g., `v0.42.1`) made after a stable release, based on a dedicated release branch. + +Each type plays a distinct role in delivering reliable and tested updates while allowing ongoing development to continue smoothly. + +## Release Candidates + +Release candidates are Cozystack versions that introduce new features and are published before a stable release. +Their purpose is to help validate stability before finalizing a new feature release. +They allow for final rounds of testing and bug fixes without freezing development. + +Release candidates are given numbers `vX.Y.0-rc.N`, for example, `v0.42.0-rc.1`. +They are created directly in the `main` branch. +An RC is typically tagged when all major features for the upcoming release have been merged into main and the release enters its testing phase. +However, new features and changes can still be added before the regular release `vX.Y.0`. + +Each RC contributes to a cumulative set of release notes that will be finalized when `vX.Y.0` is released. +After testing, if no critical issues remain, the regular release (`vX.Y.0`) is tagged from the last RC or a later commit in main. +This begins the regular release process, creates a dedicated `release-X.Y` branch, and opens the way for patch releases. ## Regular Releases -When making regular releases, we take a commit in `main` and decide to make it a release `x.y.0`. +When making a regular release, we tag the latest RC or a subsequent minimal-change commit as `vX.Y.0`. In this explanation, we'll use version `v0.42.0` as an example: ```mermaid From 70fed8148d2d7199ddd3cfdba783c05a153ef412 Mon Sep 17 00:00:00 2001 From: Nick Volynkin Date: Mon, 5 May 2025 11:57:02 +0300 Subject: [PATCH 2/2] [ci] Run pre-commit checks even on doc changes Pre-commit is now required to merge PRs, so let it run even on documentation updates. An alternative is to merge with administrator permissions, bypassing rules, which is not a good practice. Signed-off-by: Nick Volynkin --- .github/workflows/pre-commit.yml | 2 -- 1 file changed, 2 deletions(-) diff --git a/.github/workflows/pre-commit.yml b/.github/workflows/pre-commit.yml index 8556c2bd..65c48051 100644 --- a/.github/workflows/pre-commit.yml +++ b/.github/workflows/pre-commit.yml @@ -3,8 +3,6 @@ name: Pre-Commit Checks on: pull_request: types: [labeled, opened, synchronize, reopened] - paths-ignore: - - '**.md' concurrency: group: pre-commit-${{ github.workflow }}-${{ github.event.pull_request.number }}