Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0NVq-0006qM-Ar for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Nov 2022 13:52:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p0NVp-0000XR-5i for pgsql-hackers@arkaria.postgresql.org; Wed, 30 Nov 2022 13:52:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0NVo-0000Wl-Sm for pgsql-hackers@lists.postgresql.org; Wed, 30 Nov 2022 13:52:32 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0NVn-0000BQ-D0 for pgsql-hackers@postgresql.org; Wed, 30 Nov 2022 13:52:32 +0000 Received: from bruce by momjian.us with local (Exim 4.94.2) (envelope-from ) id 1p0NVf-007OKm-Ay; Wed, 30 Nov 2022 08:52:23 -0500 Date: Wed, 30 Nov 2022 08:52:23 -0500 From: Bruce Momjian To: Peter Eisentraut Cc: Laurenz Albe , Simon Riggs , Robert Treat , Alvaro Herrera , Erik Rijkers , Justin Pryzby , PostgreSQL Hackers Subject: Re: New docs chapter on Transaction Management and related changes Message-ID: References: <80a5fd9c080d66e62f90c9565e3e1b54e61f584c.camel@cybertec.at> <3603e6e85544daa5300c7106c31bc52673711cd0.camel@cybertec.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 30, 2022 at 07:33:44AM +0100, Peter Eisentraut wrote: > On 30.11.22 02:51, Bruce Momjian wrote: > > Patch applied back to PG 11. Thanks to Simon for getting this important > > information in our docs, and for the valuable feedback from others that > > made this even better. > > I request that the backpatching of this be reverted. We don't want to have > major chapter numbers in the documentation changing between minor releases. Uh, how do others feel about this? I wanted to get this information to all our supported releases as soon as possible, rather than waiting for PG 16 and for people to upgrade. To me it seems the chapter renumbering is worth that benefit. I could put the new chapter inside an existing numbered section in the back branches if people prefer that, but then PG 16 would have it in a different place, which seems bad. > More generally, major documentation additions shouldn't be backpatched, for > the same reasons we don't backpatch features. I don't see how documentation additions and feature additions are comparable. Feature additions change the behavior of the system, and potentially introduce application breakage and bugs, while documentation additions, if they apply to the supported version, have no such risks. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Embrace your flaws. They make you human, rather than perfect, which you will never be.