On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark <st...@mit.edu> wrote: > On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark <st...@mit.edu> wrote: >> >> The code is here: >> >> https://github.com/gsstark/retropg >> >> The build script is called "makeall" and it applies patches from the >> "old-postgres-fixes" directory though some of the smarts are in the >> script because it knows about how to run older version of the >> configure script and it tries to fix up the ecpg parser duplcate >> tokens separately. It saves a diff after applying the patches and >> other fixups into the "net-diffs" directory but I've never checked if >> those diffs would work cleanly on their own. > > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
