From c2e82ece8b1adaa9b77b9e52c23c4be88f7cda9c Mon Sep 17 00:00:00 2001 From: Juliana Fajardini Date: Wed, 3 Dec 2025 20:12:42 -0300 Subject: [PATCH] devguide: update backports policy for Suricata 7.0 Also remove mentions to `master` and `6.0x`. Task #7937 (cherry picked from commit 6c06ab614403d337b5ea1b05e85343bc413e3ae2) --- .../devguide/contributing/backports-guide.rst | 24 ++++++++++++------- .../contributing/contribution-process.rst | 2 +- 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/doc/userguide/devguide/contributing/backports-guide.rst b/doc/userguide/devguide/contributing/backports-guide.rst index b9bf287247..03cfbe0d14 100644 --- a/doc/userguide/devguide/contributing/backports-guide.rst +++ b/doc/userguide/devguide/contributing/backports-guide.rst @@ -7,14 +7,14 @@ Suricata releases. Most often, this means security and/or bug fixes; however, in some cases, features may be backported to previous Suricata releases. There are multiple versions of Suricata at any given time: - * Master + * Main * Major stable release * Old stable release For example, at the moment, there are 3 releases based on these Suricata branches: - * main: 8.0.0-dev, current development branch - * main-7.0.x: major stable release (note we're changing our naming conventions) - * master-6.0.x: old stable release + * main: 9.0.0-dev, current development branch + * main-8.0.x: major stable release + * main-7.0.x: old stable release For Suricata's release cadence and *end of life* policies, please check https://suricata.io/our-story/eol-policy/. @@ -38,6 +38,12 @@ The general principle used to determine what will be backported is: * in some cases, new features are backported if there are sufficient reasons to backport a new feature. +.. note:: 7.0.x backports + + With the release of Suricata 8.0, Suricata 7 has reached a mature stage of its + release cycle. Thus, as a rule, only critical issues (bugs and security), + should be considered for backporting. + .. Note:: Exceptions There can be cases where backports may be "missed" -- some issues may not be @@ -63,10 +69,10 @@ Creating backport tickets -- new issues Redmine: for security and bug fixes, when creating a new Redmine issue, label the Redmine issue with "Needs backport to x.0", where x.0 is a supported -Suricata release, e.g, 7.0.x. +Suricata release, e.g, 8.0.x. -Creating backports tickets -- existing issues/PRs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Creating backport tickets -- existing issues/PRs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We want to minimize the occurrence of "missed backports" -- that is, work that should be backported but wasn't. Sometimes this happens when there is no Redmine @@ -94,7 +100,7 @@ backporting process once the PR for main has been merged. Then: backported. * *Bring each commit into the new branch,* one at a time -- starting with the oldest commit. Use ``git cherry-pick -x commit-hash``, where ``commit-hash`` - is the hash to the commit already in main or main-7.0x that is being + is the hash to the commit already in main or main-8.0x that is being backported, as it maintains the linkage with said cherry-picked commit. * *Resolve conflicts:* Some of the cherry-picked commits may contain merge conflicts. If the conflicts are small, include the corrections in the @@ -116,7 +122,7 @@ Create a PR: ~~~~~~~~~~~~ Please indicate in the title that this is a backport PR, with something like -*(7.0.x-backport)*, and add the related milestone label. +*(8.0.x-backport)*, and add the related milestone label. In the PR description, indicate the backport ticket. diff --git a/doc/userguide/devguide/contributing/contribution-process.rst b/doc/userguide/devguide/contributing/contribution-process.rst index 2db105bb77..04a30f6434 100644 --- a/doc/userguide/devguide/contributing/contribution-process.rst +++ b/doc/userguide/devguide/contributing/contribution-process.rst @@ -181,8 +181,8 @@ What branch to work on There are usually 2 or 3 active branches: - * master-x.x.x (e.g. master-6.0.x) * main-x.x.x (e.g. main-7.0.x) + * main-x.x.x (e.g. main-8.0.x) * main The ones with version numbers are stable branches. **main** is the development branch.