From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DA28F158042 for ; Tue, 29 Oct 2024 17:40:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02802E0824; Tue, 29 Oct 2024 17:40:37 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E0002E0824 for ; Tue, 29 Oct 2024 17:40:36 +0000 (UTC) Received: from oystercatcher.gentoo.org (oystercatcher.gentoo.org [148.251.78.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 00881342FB6 for ; Tue, 29 Oct 2024 17:40:36 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id 66EE111DF for ; Tue, 29 Oct 2024 17:40:34 +0000 (UTC) From: "Ulrich Müller" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Ulrich Müller" Message-ID: <1730219778.267ff220678b04b39acc3d32b6dfaea8c57d51ff.ulm@gentoo> Subject: [gentoo-commits] proj/devmanual:master commit in: general-concepts/ebuild-revisions/ X-VCS-Repository: proj/devmanual X-VCS-Files: general-concepts/ebuild-revisions/text.xml X-VCS-Directories: general-concepts/ebuild-revisions/ X-VCS-Committer: ulm X-VCS-Committer-Name: Ulrich Müller X-VCS-Revision: 267ff220678b04b39acc3d32b6dfaea8c57d51ff X-VCS-Branch: master Date: Tue, 29 Oct 2024 17:40:34 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: 37ff4177-bbc3-489c-ad21-d1b9245ecd5c X-Archives-Hash: 8c79af7d2e7aa5b38c229534442f5994 commit: 267ff220678b04b39acc3d32b6dfaea8c57d51ff Author: Ulrich Müller gentoo org> AuthorDate: Tue Oct 29 16:20:20 2024 +0000 Commit: Ulrich Müller gentoo org> CommitDate: Tue Oct 29 16:36:18 2024 +0000 URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=267ff220 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 gentoo.org> general-concepts/ebuild-revisions/text.xml | 24 ++++++++++++------------ 1 file 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,23 +29,28 @@ revision.

Developers are encouraged to use common sense when determining -whether to introduce a new -rX revision. The following rule +whether to introduce a new -rX revision. The following rules of thumb could be used as a guideline:

+
  1. 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 ~arch (see - ). + 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.
    2. +
  2. + 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 ~arch (see ). + The general guideline here is conservatism and the need to minimize + the risk of accidental breakage for stable users. +
    3. +
  3. If the change makes a substantial difference to the user who already installed the package (fixes runtime issues, changes installed files, @@ -125,11 +130,6 @@ of thumb could be used as a guideline:
    4. -

    -Note that the examples above should still be balanced against the general -principle of conservatism and need to minimize risk for stable users. -

    -