aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorUlrich Müller <ulm@gentoo.org>2024-10-29 17:20:20 +0100
committerUlrich Müller <ulm@gentoo.org>2024-10-29 17:36:18 +0100
commit267ff220678b04b39acc3d32b6dfaea8c57d51ff (patch)
treef593c5167900ce7f706d731ffe83337a5b30602c
parentgeneral-concepts/ebuild-revisions: mention balancing examples against stable (diff)
downloaddevmanual-267ff220678b04b39acc3d32b6dfaea8c57d51ff.tar.gz
devmanual-267ff220678b04b39acc3d32b6dfaea8c57d51ff.tar.bz2
devmanual-267ff220678b04b39acc3d32b6dfaea8c57d51ff.zip
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@gentoo.org>
-rw-r--r--general-concepts/ebuild-revisions/text.xml24
1 files 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,24 +29,29 @@ 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,
etc.) and it would not be propagated using other means, then
@@ -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>