On 10/25/21 13:09, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>>> 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.
>> I'd really like us to adopt a "default" policy on this. I think it's a waste
>> to spend time every few years arguing what exact versions to drop. I'd much
>> rather say that, unless there are concrete reasons to deviate from that, we
>> provide pg_dump compatibility for 5+3 releases, pg_upgrade for 5+1, and psql
>> for 5 releases or something like that.
> I agree with considering something like that to be the minimum support
> policy, but the actual changes need a bit more care. For example, when
> we last did this, the technical need was just to drop pre-7.4 versions,
> but we chose to make the cutoff 8.0 on the grounds that that was more
> understandable to users [1]. In the same way, I'm thinking of moving the
> cutoff to 9.0 now, although 8.4 would be sufficient from a technical
> standpoint.
>
> OTOH, in the new world of one-part major versions, it's less clear that
> there will be obvious division points for future cutoff changes. Maybe
> versions-divisible-by-five would work? Or versions divisible by ten,
> but experience so far suggests that we'll want to move the cutoff more
> often than once every ten years.
>
>
pg_upgrade claims to be able to operate on 8.4, which might be all the
better for some regular testing (which this could enable), so that seems
to me more like where the cutoff should be at least for this round.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
