Robert Haas <robertmh...@gmail.com> writes:
> On Sun, Dec 5, 2021 at 7:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Based on these results, I think maybe we should raise our ambitions
>> a bit compared to Peter's original proposal. Specifically,
>> I wonder if it wouldn't be wise to try to silence compile warnings
>> in these branches.
> Yep. I have long been of the view, and have said before, that there is
> very little harm in doing some maintenance of EOL branches. Making it
> easy to test against them is a great way to improve our chances of
> actually having the amount of backward-compatibility that we say we
> want to have.
Right. The question that's on the table is how much is the right
amount of maintenance. I think that back-patching user-visible bug
fixes, for example, is taking things too far. What we want is to
be able to replicate the behavior of the branch's last released
version, using whatever build tools we are currently using. So
back-patching something like that is counterproductive, because
now the behavior is not what was released.
A minimal amount of maintenance would be "only back-patch fixes
for issues that cause failure-to-build". The next step up is "fix
issues that cause failure-to-pass-regression-tests", and then above
that is "fix developer-facing annoyances, such as compiler warnings
or unwanted test output, as long as you aren't changing user-facing
behavior". I now think that it'd be reasonable to include this
last group, although I'm pretty sure Peter didn't have that in mind
in his policy sketch.
regards, tom lane
