Commit ac48712d83 for frr
commit ac48712d83348ed03324e50e6e17bcb875699407
Author: Jafar Al-Gharaibeh <jafar@atcorp.com>
Date: Mon Sep 14 22:32:39 2026 -0500
doc: skip dev/ branches and refresh the 10.8 release schedule
Fork stable/X.Y directly at the 4-week mark, tag base_X.Y there, and bump
master to the next -dev series. Drop the old rename-from-dev steps and
start the timeline at the next freeze.
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
diff --git a/doc/developer/frr-release-procedure.rst b/doc/developer/frr-release-procedure.rst
index 5a2ad55db2..04c82d67ba 100644
--- a/doc/developer/frr-release-procedure.rst
+++ b/doc/developer/frr-release-procedure.rst
@@ -29,29 +29,17 @@ Stage 1 - Preparation
.. code-block:: console
- ./tools/release_notes.py -b dev/9.1 -t frr-9.0.1
+ ./tools/release_notes.py -b stable/10.8 -t frr-10.7.0
- dev/9.1 is the branch to be renamed to stable/9.1, and frr-9.0.1 in this
- example is the latest tag from which to generate the logs.
+ ``stable/10.8`` is the upcoming release branch (forked from master four
+ weeks before the release date), and ``frr-10.7.0`` in this example is the
+ latest tag from which to generate the logs.
-#. Checkout the existing ``dev/<version>`` branch.
+#. Checkout the existing ``stable/<version>`` branch.
.. code-block:: console
- git checkout dev/<version>
-
-#. Create and push a new branch called ``stable/<version>`` based on the
- ``dev/<version>`` branch.
-
- .. code-block:: console
-
- git checkout -b stable/<version>
-
-#. Remove the development branch called ``dev/<version>``
-
- .. code-block:: console
-
- git push origin --delete dev/<version>
+ git checkout stable/<version>
#. Update Changelog for Red Hat Packages:
diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst
index c93bd751a5..62351f4a45 100644
--- a/doc/developer/workflow.rst
+++ b/doc/developer/workflow.rst
@@ -95,16 +95,23 @@ March/July/November. Walking backwards from this date:
- 6 weeks earlier, ``master`` is frozen for new features, and feature PRs
are considered lowest priority (regardless of when they were opened.)
- - 4 weeks earlier, the stable branch separates from master (named
- ``dev/MAJOR.MINOR`` at this point) and tagged as ``base_X.Y``.
+ - 4 weeks earlier, the stable branch separates from master as
+ ``stable/MAJOR.MINOR`` and is tagged as ``base_X.Y``.
Master is unfrozen and new features may again proceed.
+ There is no intermediate ``dev/`` branch; the upcoming release is
+ tracked on ``stable/`` from this point on.
Part of unfreezing master is editing the ``AC_INIT`` statement in
- :file:`configure.ac` to reflect the new development version that master
- now refers to. This is accompanied by a ``frr-X.Y.Z-dev`` tag on master,
- which should always be on the first commit on master *after* the stable
- branch was forked (even if that is not the edit to ``AC_INIT``; it's more
- important to have it on the very first commit on master after the fork.)
+ :file:`configure.ac` to reflect the next development version that master
+ now refers to. This is accompanied by a ``frr-X.Y.Z-dev`` tag on master
+ (for that next version), which should always be on the first commit on
+ master *after* the stable branch was forked (even if that is not the edit
+ to ``AC_INIT``; it's more important to have it on the very first commit on
+ master after the fork.)
+
+ ``base_X.Y`` tags the fork point of ``stable/X.Y``, the branch that tracks
+ the upcoming release. It is not the start of the new development series
+ on master; that is the ``frr-*.*-dev`` tag created after the bump below.
(The :file:`configure.ac` edit and tag push are considered git housekeeping
and are pushed directly to ``master``, not through a PR.)
@@ -119,17 +126,17 @@ March/July/November. Walking backwards from this date:
% git checkout master
% git pull upstream master
- % git checkout -b dev/10.5
- % git tag base_10.5
- % git push upstream base_10.5
- % git push upstream dev/10.5
+ % git checkout -b stable/10.8
+ % git tag base_10.8
+ % git push upstream base_10.8
+ % git push upstream stable/10.8
% git checkout master
- % sed -i 's/10.4.0-dev/10.5.0-dev/' configure.ac
+ % sed -i 's/10.8.0-dev/10.9.0-dev/' configure.ac
% git add configure.ac
- % git commit -s -m "build: FRR 10.5.0 development version"
- % git tag -a frr-10.5.0-dev -m "frr-10.5.0-dev"
+ % git commit -s -m "build: FRR 10.9.0 development version"
+ % git tag -a frr-10.9.0-dev -m "frr-10.9.0-dev"
% git push upstream master
- % git push upstream frr-10.5.0-dev
+ % git push upstream frr-10.9.0-dev
In this step, we also have to update package versions to reflect
the development version. Versions need to be updated using
@@ -141,7 +148,7 @@ March/July/November. Walking backwards from this date:
files on the release branch need to be cherry-picked to the master branch.
Update essential dates in advance for reference table (below) when
- the next freeze, dev/X.Y, RC, and release phases are scheduled. This should
+ the next freeze, stable/X.Y, RC, and release phases are scheduled. This should
go in the ``master`` branch.
- The zebra dataplane API is versioned separately from the FRR
@@ -159,11 +166,12 @@ March/July/November. Walking backwards from this date:
upstream git@github.com:frrouting/frr (fetch)
upstream git@github.com:frrouting/frr (push)
- % git checkout dev/10.5
- % git tag frr-10.5.0-rc
- % git push upstream frr-10.5.0-rc
+ % git checkout stable/10.8
+ % git tag frr-10.8.0-rc
+ % git push upstream frr-10.8.0-rc
- - on release date, the branch is renamed to ``stable/MAJOR.MINOR``.
+ - on release date, ``frr-X.Y.Z`` is tagged on ``stable/MAJOR.MINOR``.
+ The branch is already named ``stable/``; it is not renamed at release time.
The 2 week window between each of these events should be used to run any and
all testing possible for the release in progress. However, the current
@@ -210,7 +218,7 @@ Here is the hint on how to get the dates easily:
echo ""
echo "Release Month: $(date -d "$release_date" +%B)"
echo " Freeze date: $freeze_date"
- echo " dev/X.Y.Z date: $dev_date"
+ echo " stable/X.Y date: $dev_date"
echo " RC date: $rc_date"
echo " Release date: $release_date"
done
diff --git a/doc/figures/releases.dot b/doc/figures/releases.dot
index 2ada79257d..30033ab903 100644
--- a/doc/figures/releases.dot
+++ b/doc/figures/releases.dot
@@ -2,12 +2,12 @@ digraph ReleaseTimeline {
rankdir=LR;
node [shape=box, style=rounded, fontsize=10, width=1.5, fontname="Helvetica"];
- subgraph cluster_dev {
- label="Development";
+ subgraph cluster_stable_branch {
+ label="Stable branch";
style=dashed;
color=blue;
node [fillcolor=lightblue, style=filled];
- "dev/X.Y.Z";
+ "stable/X.Y";
}
subgraph cluster_rc {
@@ -28,18 +28,18 @@ digraph ReleaseTimeline {
// Release steps with actions
"freeze" [label="Freeze", shape=ellipse, style=dotted, fontcolor=red];
- "dev/X.Y.Z" [label="dev/X.Y.Z\n(Development)", fillcolor=lightblue];
+ "stable/X.Y" [label="stable/X.Y\n(branch fork)", fillcolor=lightblue];
"RC" [label="RC\n(Release Candidate)", fillcolor=orange];
"release" [label="Release\n(Final)", fillcolor=lightgreen];
// Connect the steps with actions
- "freeze" -> "dev/X.Y.Z" [label=" "];
- "dev/X.Y.Z" -> "RC" [label=" "];
+ "freeze" -> "stable/X.Y" [label=" "];
+ "stable/X.Y" -> "RC" [label=" "];
"RC" -> "release" [label=" "];
- // Date connections (freeze -> dev/X.Y.Z -> RC -> release)
+ // Date connections (freeze -> stable/X.Y -> RC -> release)
"2026-09-22" -> "2026-10-06" -> "2026-10-20" -> "2026-11-03";
- "2026-05-26" -> "2026-06-09" -> "2026-06-23" -> "2026-07-07";
- "2026-01-20" -> "2026-02-03" -> "2026-02-17" -> "2026-03-03";
- "2025-09-23" -> "2025-10-07" -> "2025-10-21" -> "2025-11-04";
+ "2027-01-19" -> "2027-02-02" -> "2027-02-16" -> "2027-03-02";
+ "2027-05-25" -> "2027-06-08" -> "2027-06-22" -> "2027-07-06";
+ "2027-09-21" -> "2027-10-05" -> "2027-10-19" -> "2027-11-02";
}