Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark <stark@mit.edu> wrote:
>> Fwiw I was considering proposing committing some patches for these old
>> releases to make them easier to build. I would suggest creating a tag
>> for a for this stable legacy version and limiting the commits to just:
>>
>> 1) Disabling warnings
>> 2) Fixing bugs in the configure scripts that occur on more recent
>> systems (version number parsing etc)
>> 3) Backporting things like the variable-length array code that prevents building
>> 4) Adding compiler options like -fwrapv
> I'd support that. The reason why we remove branches from support is
> so that we don't have to back-patch things to 10 or 15 branches when
> we have a bug fix. But that doesn't mean that we should prohibit all
> commits to those branches for any reason, and making it easier to test
> backward-compatibility when we want to do that seems like a good
> reason.
Meh, I think that this will involve a great deal more work than it's
worth. We deal with moving-target platforms *all the time*. New compiler
optimizations break things, libraries such as OpenSSL whack things around,
other libraries such as uuid-ossp stop getting maintained and become
unusable on new platforms, bison decides to get stickier about comma
placement, yadda yadda yadda. How much of that work are we going to
back-port to dead branches? And to what extent is such effort going to be
self-defeating because the branch no longer behaves as it did back in the
day?
If Greg wants to do this kind of work, he's got a commit bit. My position
is that we have a limited support lifespan for a reason, and I'm not going
to spend time on updating dead branches forever. To me, it's more useful
to test them in place on contemporary platforms. We've certainly got
enough old platforms laying about in the buildfarm and elsewhere.
regards, tom lane