"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Fri, Oct 22, 2021 at 3:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Anyway, I think the default answer is "revert 92316a458 and keep the
>> compatibility goalposts where they are". But I wanted to open up a
>> discussion to see if anyone likes the other approach better.
> ... IMO, the bar for this kind of situation should be 10 releases at
> most - 5 of which would be in support at the time the patch goes in. We
> don't have to actively drop support of older stuff but anything older
> shouldn't be preventing new commits.
Yeah. I checked into when it was that we dropped pre-8.0 support
from pg_dump, and the answer is just about five years ago (64f3524e2).
So moving the bar forward by five releases isn't at all out of line.
8.4 would be eight years past EOL by the time v15 comes out.
One of the arguments for the previous change was that it was getting
very hard to build old releases on modern platforms, thus making it
hard to do any compatibility testing. I believe the same is starting
to become true of the 8.x releases, though I've not tried personally
to build any of them in some time. (The executables I'm using for
them date from 2014 or earlier, and have not been recompiled in
subsequent platform upgrades ...) Anyway it's definitely not free
to continue to support old source server versions.
regards, tom lane
