Message-ID: <5dd7ec9c-0a46-6c77-1176-caca0c68c3c1@enterprisedb.com>
Date: Fri, 3 Dec 2021 17:19:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.3.2
Subject: Re: pg_dump versus ancient server versions
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>,
 Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
 <202110222351.3f42l5fgo3lw@alvherre.pgsql>
 <CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
 <3783090.1635111977@sss.pgh.pa.us>
 <CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
 <3883429.1635171820@sss.pgh.pa.us>
 <20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
 <c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
 <22018.1635202338@sss.pgh.pa.us>
 <d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
 <2073703.1638466245@sss.pgh.pa.us>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <2073703.1638466245@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/5dd7ec9c-0a46-6c77-1176-caca0c68c3c1%40enterprisedb.com>
Precedence: bulk

On 02.12.21 18:30, Tom Lane wrote:
>> This assumes a yearly major release cadence.
> 
> If the point is to not have to count dates carefully, why does the cadence
> matter?

If we were to change the release cadence, then it would be appropriate 
to review this policy.

> I can get behind something roughly like this, but I wonder if it wouldn't
> be better to formulate the policy in a reactive way, i.e. when X happens
> we'll do Y.  If we don't plan to proactively remove some code every year,
> then it seems like the policy really is more like "when something breaks,
> then we'll make an attempt to keep it working if the release is less than
> ten majors back; otherwise we'll declare that release no longer
> buildable."

This sounds like it would give license to accidentally break support for 
old releases in the code and only fix them if someone complains.  That's 
not really what I would be aiming for.

> I agree with the idea of being conservative about what outside
> dependencies we will worry about for "buildable" old versions.
> (Your nearby message about Python breakage is a good example of
> why we must limit that.)  But I wonder about, say, libxml or libicu,
> or even if we can afford to drop all the non-plpgsql PLs.  An
> example of why that seems worrisome is that it's not clear we'd
> have any meaningful coverage of transforms in pg_dump with no PLs.
> I don't have any immediate proposal here, but it seems like an area
> that needs some thought and specific policy.

Yeah, I think questions like this will currently quickly lead to dead 
ends.  We are talking 5 years this, 10 years that here.  Everybody else 
(apart from RHEL) is talking at best in the range 3-5 years.  We will 
have to figure this out as we go.