Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1waLBd-001jQl-1b for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2026 22:26:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1waLBc-00Dtoi-0l for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2026 22:26:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1waLBb-00Dtoa-36 for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2026 22:26:11 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1waLBZ-00000001Af6-36Gz for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2026 22:26:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 65IMQ6Cs1403991; Thu, 18 Jun 2026 18:26:07 -0400 From: Tom Lane To: Jacob Champion cc: PostgreSQL Hackers Subject: Re: PG20 Minimum Dependency Thread In-reply-to: References: <1399933.1781817745@sss.pgh.pa.us> Comments: In-reply-to Jacob Champion message dated "Thu, 18 Jun 2026 14:42:50 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1403989.1781821566.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Thu, 18 Jun 2026 18:26:06 -0400 Message-ID: <1403990.1781821566@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jacob Champion writes: > On Thu, Jun 18, 2026 at 2:22 PM Tom Lane wrote: >> so it kind of doesn't >> matter today whether we set N to 2 or 3. > I think it still matters for impending decisions. For example, we're > about to engineer how to backport a sliding window of Python across > the sliding window of backbranch support. Shorter windows tie our > hands less. I dunno. One of the points of the allegedly-agreed-to policy framework was >>> 2) We don't remove support for OS versions in minor releases A strict reading of that is that a released branch can't increase its minimum required Python version. Now maybe we can finesse that, like "you can build PL/Python and associated contrib modules with Python >= X, but if you want to run these optional tests, they require Python >= Y". Not sure how comfortable I am with that. I definitely don't want to get into a situation where we require buildfarm owners to have Python >= Y installed, because then we will not have any testing that proves we didn't break the other part. (So we'd need a runtime check to skip these tests on too-old Python.) In any case, if we do make such a decision, most likely we'd use the same value of Y for all the active back branches. So I think the value of N in the support policy really only matters for future version-cutoff decisions. regards, tom lane