"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

                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to