Re: What about Perl autodie?

Поиск
Список
Период
Сортировка
От Dagfinn Ilmari Mannsåker
Тема Re: What about Perl autodie?
Дата
Msg-id 871q9mly5x.fsf@wibble.ilmari.org
обсуждение исходный текст
Ответ на Re: What about Perl autodie?  (Daniel Gustafsson <daniel@yesql.se>)
Список 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 по дате отправления:

Предыдущее
От: Greg Sabino Mullane
Дата:
Сообщение: Re: What about Perl autodie?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Put genbki.pl output into src/include/catalog/ directly