diff options
author | Ulrich Müller <ulm@gentoo.org> | 2024-10-29 17:20:20 +0100 |
---|---|---|
committer | Ulrich Müller <ulm@gentoo.org> | 2024-10-29 17:36:18 +0100 |
commit | 267ff220678b04b39acc3d32b6dfaea8c57d51ff (patch) | |
tree | f593c5167900ce7f706d731ffe83337a5b30602c | |
parent | general-concepts/ebuild-revisions: mention balancing examples against stable (diff) | |
download | devmanual-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.xml | 24 |
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> |