Re: What about Perl autodie? - Mailing list pgsql-hackers

From Dagfinn Ilmari Mannsåker
Subject Re: What about Perl autodie?
Date
Msg-id 871q9mly5x.fsf@wibble.ilmari.org
Whole thread Raw
In response to Re: What about Perl autodie?  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:

>> On 8 Feb 2024, at 16:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> 2. Don't wait, migrate them all now.  This would mean requiring
>> Perl 5.10.1 or later to run the TAP tests, even in back branches.
>> 
>> I think #2 might not be all that radical.  We have nothing older
>> than 5.14.0 in the buildfarm, so we don't really have much grounds
>> for claiming that 5.8.3 will work today.  And 5.10.1 came out in
>> 2009, so how likely is it that anyone cares anymore?
>
> I would vote for this option, if we don't run the trailing edge anywhere where
> breakage is visible to developers then it is like you say, far from guaranteed
> to work.

The oldest Perl I'm aware of on a still-supported (fsvo) OS is RHEL 6,
which shipped 5.10.1 and has Extended Life-cycle Support until
2024-06-30.

For comparison, last year the at the Perl Toolchain Summit in Lyon we
decided that toolchain modules (the modules needed to build, test and
install CPAN distributions) are only required support versions of Perl
up to 10 years old, i.e. currently 5.18 (but there's a one-time
excemption to keep it to 5.16 until RHEL 7 goes out of maintenance
support on 2024-06-30).

- ilmari



pgsql-hackers by date:

Previous
From: Greg Sabino Mullane
Date:
Subject: Re: What about Perl autodie?
Next
From: Tom Lane
Date:
Subject: Re: Put genbki.pl output into src/include/catalog/ directly