commit: 253075dc4fcb9cac1567caff2891e47fd76453f4 Author: Michał Górny <mgorny <AT> gentoo <DOT> org> AuthorDate: Sun Aug 6 12:25:23 2017 +0000 Commit: Göktürk Yüksek <gokturk <AT> gentoo <DOT> org> CommitDate: Mon Sep 25 04:14:52 2017 +0000 URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=253075dc
general-concepts/ebuild-revisions: Provide examples for when to revbump or not Provide a wider set of examples when to revbump or not. general-concepts/ebuild-revisions/text.xml | 51 ++++++++++++++++++++++++++---- 1 file changed, 44 insertions(+), 7 deletions(-) diff --git a/general-concepts/ebuild-revisions/text.xml b/general-concepts/ebuild-revisions/text.xml index d18d333..c370d27 100644 --- a/general-concepts/ebuild-revisions/text.xml +++ b/general-concepts/ebuild-revisions/text.xml @@ -62,13 +62,50 @@ of thumb could be used as a guideline: </li> </ol> -<p> -Simple compile fixes do <b>not</b> warrant a revision bump; this is because they do -not affect the installed package for users who already managed to compile it. -Small documentation fixes are also usually not grounds for a new revision. -In particular, this applies if the package has a substantial compilation -time; developers should use their best judgement in these circumstances. -</p> +<p>Examples of changes that warrant a new revision are:</p> +<ul> + <li>adding a patch to fix a runtime issue,</li> + <li>installing additional files that could be useful to the user,</li> + <li>adding a missing runtime dependency to one of the existing blocks,</li> + <li> + adding a missing build-time dependency that contributed to + a successfully yet incorrect build (e.g. missing some feature), + </li> + <li> + restricting a runtime dependency version, unless the <c>:=</c> + subslot operator is going to trigger a rebuild. + </li> +</ul> + +<p>Examples of changes that can be done without a revision bump are:</p> +<ul> + <li> + adding a patch to fix a build-time issue that prevented users from + building the package (since it does not affect users who already + managed to build it), + </li> + <li>adding a trivial documentation fix,</li> + <li> + installing an additional file of relatively little value (minor + documentation, editor syntax file, bash completion) compared + to the cost of rebuilding the package (especially if a new bump + is expected soon), + </li> + <li> + adding a missing build-time dependency that caused a build failure, + </li> + <li> + adding a new USE flag or removing an existing one (since change + in USE flags is going to trigger <c>--changed-use</c> rebuild), + </li> + <li> + a trivial stylistic / ebuild code change (as long as the new code + is equivalent to the old code), + </li> + <li> + a dependency change that is a result of a package move (slot move). + </li> +</ul> </body> </chapter>
