Robert Haas <robertmhaas@gmail.com> writes:
> You know, one thing we could think about doing is patching some of the
> older branches to make them compile on modern machines. That would not
> only be potentially useful for people who are upgrading from ancient
> versions, but also for hackers trying to do research on the origin of
> bugs or performance problems, and also for people who are trying to
> maintain some kind of backward compatibility or other and want to test
> against old versions.
Yeah. We have done that in the past; I thought more than once,
but right now the only case I can find is d13f41d21/105f3ef49.
There are some other post-EOL commits in git, but I think the
others were mistakes from over-enthusiastic back-patching, while
that one was definitely an intentional portability fix for EOL'd
versions.
> I don't know whether that's really worth the effort and I expect Tom
> will say that it's not. If he does say ,that, he may be right.
Hmm ... I guess the question is how much work we feel like putting
into that, and how we'd track whether old branches still work,
and on what platforms. It could easily turn into a time sink
that's not justified by the value. I do see your point that there's
some value in it; I'm just not sure about the cost/benefit ratio.
One thing we could do that would help circumscribe the costs is to say
"we are not going to consider issues involving new compiler warnings
or bugs caused by more-aggressive optimization". We could mechanize
that pretty effectively by changing configure shortly after a branch's
EOL to select -O0 and no extra warning flags, so that anyone building
from branch tip would get those switch choices.
(I have no idea what this might look like on the Windows side, but
I'm concerned by the fact that we seem to need fixes every time a
new Visual Studio major version comes out.)
regards, tom lane
