Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 02.12.21 23:16, Andres Freund wrote:
>> I realize it's more complicated for users, but a policy based on supporting a
>> certain number of out-of-support branches calculated from the newest major
>> version is more realistic. I'd personally go for something like newest-major -
>> 7 (i.e. 2 extra releases), but I realize that others think it's worthwhile to
>> support a few more. I think there's a considerable advantage of having one
>> cutoff date across all branches.
> I'm not sure it will be clear what this would actually mean. Assume
> PG11 supports back to 9.4 (14-7) now, but when PG15 comes out, we drop
> 9.4 support. But the PG11 code hasn't changed, and PG9.4 hasn't changed,
> so it will most likely still work. Then we have messaging that is out
> of sync with reality. I can see the advantage of this approach, but the
> communication around it might have to be refined.
I don't find this suggestion to be an improvement over Peter's original
formulation, for two reasons:
* I'm not convinced that it saves us any actual work; as you say, the
code doesn't stop working just because we declare it out-of-support.
* There's a real-world use-case underneath here. If somewhere you've
discovered a decades-old server that you need to upgrade, and current
pg_dump won't dump from it, you would like it to be well-defined
which intermediate pg_dump versions you can use. So if 10.19 can
dump from that hoary server, it would not be nice if 10.20 can't;
nor if the documentation lies to you about that based on which minor
version you happen to consult.
>> I think we should explicitly limit the number of platforms we care about for
>> this purpose. I don't think we should even try to keep 8.2 compile on AIX or
>> whatnot.
> It's meant to be developer-facing, so only for platforms that developers
> use. I think that can police itself, if we define it that way.
I agree that if you care about doing this sort of test on platform X,
it's up to you to patch for that. I think Andres' concern is about
the amount of committer bandwidth that might be needed to handle
such patches submitted by non-committers. However, based on the
experiment I just ran, I think it's not really likely to be a big deal:
there are not that many problems, and most of them just amount to
back-patching something that originally wasn't back-patched.
What's most likely to happen IMO is that committers will just start
back-patching essential portability fixes into out-of-support-but-
still-in-the-buildability-window branches, contemporaneously with
the original fix. Yeah, that does mean more committer effort,
but only for a very small number of patches.
regards, tom lane