devguide: update backports policy for Suricata 7.0

Also remove mentions to `master` and `6.0x`.

Task OISF#7937

Author: jufajardini

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.
 

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.