commit: 2a7992696a79c344de41c814a756d5f9f4836f8e Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> AuthorDate: Sun May 3 16:53:26 2015 +0000 Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> CommitDate: Sun May 3 16:53:26 2015 +0000 URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=2a799269
Merge remarks about revision bumps from Developer Handbook. This is taken from proj/en/devrel/handbook/hb-policy-ebuild.xml, section "Ebuild policy", subsection "Versioning and revision bumps". Permission to reuse the CC-BY-SA-1.0 work under CC-BY-SA-2.0 (or any later version) obtained from author plasmaroo per e-mail on 2015-04-16. general-concepts/ebuild-revisions/text.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/general-concepts/ebuild-revisions/text.xml b/general-concepts/ebuild-revisions/text.xml index 9ddc39f..012745f 100644 --- a/general-concepts/ebuild-revisions/text.xml +++ b/general-concepts/ebuild-revisions/text.xml @@ -17,12 +17,16 @@ Ebuilds should have their <c>-rX</c> incremented whenever a change is made which will make a substantial difference to what gets installed by the package <d/> by substantial, we generally mean "something for which many users would want to upgrade". This is usually for bugfixes. +For any such revision bump, the new ebuild should be based on the +previous revision to ensure that fixes aren't dropped accidentally. </p> <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> <important>
