|author||Michał Górny <email@example.com>||2017-08-06 14:25:23 +0200|
|committer||Göktürk Yüksek <firstname.lastname@example.org>||2017-09-25 00:14:52 -0400|
|parent||general-concepts/ebuild-revisions: Provide a 3-step guide for when to revbump (diff)|
general-concepts/ebuild-revisions: Provide examples for when to revbump or not
Provide a wider set of examples when to revbump or not.
Diffstat (limited to 'general-concepts')
1 files 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
@@ -62,13 +62,50 @@ of thumb could be used as a guideline:
-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>Examples of changes that warrant a new revision are:</p>
+ <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>
+ adding a missing build-time dependency that contributed to
+ a successfully yet incorrect build (e.g. missing some feature),
+ restricting a runtime dependency version, unless the <c>:=</c>
+ subslot operator is going to trigger a rebuild.
+<p>Examples of changes that can be done without a revision bump are:</p>
+ 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>adding a trivial documentation fix,</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),
+ adding a missing build-time dependency that caused a build failure,
+ adding a new USE flag or removing an existing one (since change
+ in USE flags is going to trigger <c>--changed-use</c> rebuild),
+ a trivial stylistic / ebuild code change (as long as the new code
+ is equivalent to the old code),
+ a dependency change that is a result of a package move (slot move).