diff mbox series

[ovs-dev] Documentation: Clarify OVS submodule bump strategy.

Message ID 20241028102218.185208-1-dceara@redhat.com
State New
Headers show
Series [ovs-dev] Documentation: Clarify OVS submodule bump strategy. | expand

Checks

Context Check Description
ovsrobot/apply-robot success apply and check: success
ovsrobot/github-robot-_Build_and_Test success github build: passed
ovsrobot/github-robot-_ovn-kubernetes success github build: passed

Commit Message

Dumitru Ceara Oct. 28, 2024, 10:22 a.m. UTC
The documentation was a bit unclear regarding how the submodule bumps
happen.  Explicitly document that we aim to eventually point the
submodule to a stable OVS release on stable OVN branches.

Reported-by: Vladislav Odintsov <vlodintsov@k2.cloud>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2024-October/417702.html
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
---
 Documentation/internals/ovs_submodule.rst | 62 +++++++++++++----------
 1 file changed, 35 insertions(+), 27 deletions(-)
diff mbox series

Patch

diff --git a/Documentation/internals/ovs_submodule.rst b/Documentation/internals/ovs_submodule.rst
index 51f2a8c758..5b296ac6e1 100644
--- a/Documentation/internals/ovs_submodule.rst
+++ b/Documentation/internals/ovs_submodule.rst
@@ -53,44 +53,48 @@  Submodules for releases
 -----------------------
 
 For OVN releases, it is preferred for the OVS submodule to point to a stable
-release branch of OVS. Therefore, as part of the release process for OVN, we
-will point the submodule to the latest stable branch of OVS before releasing.
+release of OVS. Therefore, as part of the release process for OVN, we will
+point the submodule to the latest stable version of OVS before releasing.
 
 The exception to this is if the current OVS submodule is pointing to a commit
-that is not in a current stable branch of OVS. In that case, the submodule
+that is not in a current stable release of OVS. In that case, the submodule
 will continue to point to that particular commit. We may, however, bump the
-submodule to the next stable branch of OVS at a later time.
+submodule to the next stable version of OVS at a later time.
 
 As an example, let's assume that the OVS commit history looks something like
 this in the main branch:
 
 ::
 
-    (Newest)
-    Commit 3
-       |
-       |
-    Commit 2 (used to create OVS branch-Y)
-       |
-       |
-    Commit 1
-    (Oldest)
+             (Newest)
+             Commit 4
+                |
+                |
+             Commit 2 ------------------------------- Commit 3
+    (used to create OVS branch-Y)      (latest stable release on OVS branch-Y)
+                |
+                |
+             Commit 1
+             (Oldest)
 
 Let's say that we are planning to release OVN version X. At this point, the
-submodule is pointing to Commit 1. As part of the release process, we will bump
-the OVS submodule in OVN to point to Commit 2, or more likely the tip of OVS
-branch-Y. This way, the released version of OVN is based on a stable release
-branch of OVS, and it has all of the necessary changes that we require.
-
-What if the OVS submodule currently points to Commit 3, though? There is no
-stable branch that exists after this commit. In this case, we have two choices:
-
-# Create OVN release X and point the OVS submodule to Commit 3. At a later
-  time, if it makes sense to do so, we may bump the submodule to OVS branch-Z
-  when it is released, since Commit 3 will be included in that branch.
-# If Commit 3 is a bug fix in OVS, then we can try to ensure that Commit 3 gets
-  backported to OVS branch-Y, and then point the submodule commit to the tip of
-  OVS branch-Y.
+submodule is pointing to Commit 1. As part of the release process, we will
+bump the OVS submodule in OVN to point to Commit 2, or more likely the latest
+OVS release on branch-y (Commit 3). This way, the released version of OVN is
+based on a stable release of OVS, and it has all of the necessary changes
+that we require.
+
+What if the OVS submodule currently points to Commit 4, though? There is no
+stable OVS release that exists after this commit. In this case, we have two
+choices:
+
+# Create OVN release X and point the OVS submodule to Commit 4. At a later
+  time, if it makes sense to do so, we may bump the submodule to the new
+  OVS stable release on branch-Z when it is released, since Commit 4 will
+  be included in that branch.
+# If Commit 4 is a bug fix in OVS, then we can try to ensure that Commit 4 gets
+  backported to OVS branch-Y, and then point the submodule commit to the next
+  stable release of OVS on branch-Y.
 
 For choice 1, the decision of whether to update the submodule commit to OVS
 branch-Z is based on several factors.
@@ -101,6 +105,10 @@  branch-Z is based on several factors.
   submodule?
 - Is there risk in updating the submodule?
 
+For choice 2, it's preferable to bump to a new stable OVS release but if
+the bug fix is urgent maintainers may decide to temporarily point the OVS
+submodule bump to the tip of brach-Y.
+
 For an LTS of OVN, we might update the submodule several times during its
 lifetime as more new OVS branches are released. For a standard release, it is
 less likely that we will update the OVS submodule during the standard release's