Hi, On 2021-10-25 13:09:43 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > 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.
I think that'd be less of a concern if we had a documented policy somewhere. It'd not be hard to include a version table in that policy to make it easier to understand. We could even add it to the table in https://www.postgresql.org/support/versioning/ or something similar. > 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? I think that's more confusing than helpful, because the support timeframes then differ between releases. It's easier to just subtract a number of major releases for from a specific major version. Especially if there's a table somewhere. > 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. Yes, I think that'd be quite a bit too restrictive. Greetings, Andres Freund
