[gentoo-commits] proj/devmanual:master commit in: general-concepts/ebuild-revisions/

["Ulrich Müller" <ulm@gentoo.org>]

commit:     267ff220678b04b39acc3d32b6dfaea8c57d51ff
Author:     Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Tue Oct 29 16:20:20 2024 +0000
Commit:     Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Tue Oct 29 16:36:18 2024 +0000
URL:        https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=267ff220

general-concepts/ebuild-revisions: Almost always revbump when stable

Drop the paragraph after the example and make it a new list item with
updated wording.

Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>

 general-concepts/ebuild-revisions/text.xml | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/general-concepts/ebuild-revisions/text.xml b/general-concepts/ebuild-revisions/text.xml
index 72087f0..b657b68 100644
--- a/general-concepts/ebuild-revisions/text.xml
+++ b/general-concepts/ebuild-revisions/text.xml
@@ -29,23 +29,28 @@ revision.
 
 <p>
 Developers are encouraged to use common sense when determining
-whether to introduce a new <c>-rX</c> revision. The following rule
+whether to introduce a new <c>-rX</c> revision. The following rules
 of thumb could be used as a guideline:
 </p>
+
 <ol>
   <li>
     If the change can cause the package to be broken to the point
-    of requiring users to revert to the previous version (in the case
-    of packages marked stable, every non-trivial change is classified
-    as such), then a new revision should be introduced and the old one
-    kept. If the package has stable keywords, the new revision should
-    be dropped to <c>~arch</c> (see
-    <uri link="::keywording/#Keywording on upgrades"/>).
+    of requiring users to revert to the previous version, then a new
+    revision should be introduced and the old one kept.
     For any such revision bump, the new ebuild should be based
     on the previous revision to ensure that fixes aren't dropped
     accidentally.
   </li>
 
+  <li>
+    If the package has stable keywords, then a new revision should be
+    introduced for every non-trivial change, and its keywords should be dropped
+    to <c>~arch</c> (see <uri link="::keywording/#Keywording on upgrades"/>).
+    The general guideline here is conservatism and the need to minimize
+    the risk of accidental breakage for stable users.
+  </li>
+
   <li>
     If the change makes a substantial difference to the user who already
     installed the package (fixes runtime issues, changes installed files,
@@ -125,11 +130,6 @@ of thumb could be used as a guideline:
   </li>
 </ul>
 
-<p>
-Note that the examples above should still be balanced against the general
-principle of conservatism and need to minimize risk for stable users.
-</p>
-
 </body>
 </chapter>
 </guide>