Re: pg_dump versus ancient server versions

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 25, 2021 at 10:23 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Roughly speaking, I think the policy should be "no feature bug fixes,
>> not even security fixes, for EOL'd branches; only fixes that are
>> minimally necessary to make it build on newer platforms". And
>> I want to have a sunset provision even for that. Fixing every branch
>> forevermore doesn't scale.

> Sure, but you can ameliorate that a lot by just saying it's something
> people have the *option* to do, not something anybody is *expected* to
> do. I agree it's best if we continue to discourage back-patching bug
> fixes into supported branches, but I also think we don't need to be
> too stringent about this.

Actually, I think we do. If I want to test against 7.4, ISTM I want
to test against the last released 7.4 version, not something with
arbitrary later changes. Otherwise, what exactly is the point?

>> In principle we might just need to add resurrected branches back to
>> the branches_to_build list. Given my view of what the back-patching
>> policy ought to be, a new build in an old branch might only be
>> required a couple of times a year, which would not be an undue
>> investment of buildfarm resources.

> I suppose it would be useful if we had the ability to do new runs only
> when the source code has changed...

Uh, don't we have that already? I know you can configure a buildfarm
animal to force a run at least every-so-often, but it's not required,
and I don't think it's even the default.

regards, tom lane