|author||Ulrich Müller <email@example.com>||2015-05-03 18:53:26 +0200|
|committer||Ulrich Müller <firstname.lastname@example.org>||2015-05-03 18:53:26 +0200|
|parent||ebuild-writing: use-conditionals: Add more information about the old `use foo... (diff)|
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.
Diffstat (limited to 'general-concepts/ebuild-revisions/text.xml')
1 files changed, 4 insertions, 0 deletions
diff --git a/general-concepts/ebuild-revisions/text.xml b/general-concepts/ebuild-revisions/text.xml
index 9ddc39f..012745f 100644
@@ -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.
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.