From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_dump versus ancient server versions |
Date: | 2021-12-03 16:19:47 |
Message-ID: | 5dd7ec9c-0a46-6c77-1176-caca0c68c3c1@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2021-12-03 16:22:12 | Re: Commitfest 2021-11 closed |
Previous Message | Peter Eisentraut | 2021-12-03 15:52:10 | Re: Replace uses of deprecated Python module distutils.sysconfig |