"Tels" <nospam-pg-ab...@bloodgate.com> writes: > On Sun, July 30, 2017 1:21 am, Tom Lane wrote: >>> So the question is, does anyone care? I wouldn't except that our >>> documentation appears to claim that we work with Perl "5.8 or later".
> Not sure how often People use old Perl versions out in the field. I'd > venture this is either happens with "ancient" stuff, e.g. where people > just can't or want upgrade. > Otherwise, an up-to-date OS is just necessary for security, anyway, and > that would contain a Perl from this decade, wouldn't it? Well, that's not really the point, IMO. The reason I'm interested in this is the same reason I run some buildfarm critters on ancient platforms: if we do something that breaks backwards compatibility with old software, we should know it and make a deliberate decision that it's okay. (And update the relevant compatibility claims in our docs.) Moving the compatibility goalposts without knowing it isn't good, especially if it happens in supposedly-stable release branches. >> I am unable to confirm our claim that we work with Test::More 0.82, >> because CPAN has only versions from a year or three back. (Anyone >> know of a more, er, comprehensive archive than CPAN?) It's also >> interesting to speculate about how old a version of IPC::Run is new >> enough, but I see no easy way to get much data on that either. > Test::More has been bundled with Perl since 5.6.2 (you can use "corelist" > to check for these things), so if all fails, it might be possible to > extract a version from a Perl distribution [4]. Yeah, I looked into that. The closest candidate I can find is that perl 5.10.1 contains Test::More 0.92. However, it's not real clear to me exactly which files I'd need to pull out of 5.10.1 and inject into an older tarball --- the layout seems a lot different from a standalone package. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers