From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Jeff King <peff@peff.net>,
Eric Sunshine <sunshine@sunshineco.com>, Eric Wong <e@80x24.org>,
Jakub Narebski <jnareb@gmail.com>, Petr Baudis <pasky@suse.cz>,
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Subject: Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0
Date: Sun, 24 Dec 2017 12:57:03 +0100 [thread overview]
Message-ID: <873740s5io.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20171223231742.GF6217@genre.crustytoothpaste.net>
On Sat, Dec 23 2017, brian m. carlson jotted:
> On Sat, Dec 23, 2017 at 05:44:00PM +0000, Ævar Arnfjörð Bjarmason wrote:
>> The reason to do this is to be able to use features released with perl
>> in the last decade, 5.10 was a major feature release including things
>> like new regex features, state variables, the defined-or operator
>> etc.[3]
>>
>> I expect this to be more controversial as since the 5.8 release stayed
>> along for longer in various distributions, e.g. it's the version
>> shipped with RHEL 5, replaced by 5.10 in RHEL 6 released in late 2010,
>> similarly the first Debian release to include 5.10 was 5.0 (Lenny)
>> released in early 2009. The release history for other distributions
>> can be seen on CPAN's "Perl Binaries" page[3].
>
> This is fine by me. As far as I know, 5.10.1 is the oldest version of
> Perl still security-supported by a major Linux vendor.
>
> Feature-wise, the release I'd much rather see is 5.14, since it provides
> the r modifier to s/// and tr/// and undef-transparent length, but that
> simply won't be possible until RHEL 6 and CentOS 6 go EOL. Upgrading to
> 5.10 is better than nothing, and it does get us defined-or, which is one
> of the only 5.10 features I ever see used.
Indeed, but as you point out it's not going to happen for some time
given the burden we can reasonably place on downstream packagers.
> I'm curious, though, is there some reason you went with the "v5.10.0"
> syntax other than "5.010"? I believe the latter provides a better error
> message on older Perls, although I agree the former is more readable.
It would only provide confusing errors on 5.6 and older, which as noted
we haven't supported at all since before 2010, so people are unlikely to
be running it.
I'll note why I did that in a non-RFC commit message, FWIW this wording
was also confusing in perl's own documentation, which I fixed the other
day: https://github.com/Perl/perl5/commit/f1546a83e7
next prev parent reply other threads:[~2017-12-24 11:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-23 17:44 [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0 Ævar Arnfjörð Bjarmason
2017-12-23 17:56 ` Randall S. Becker
2017-12-23 23:17 ` brian m. carlson
2017-12-24 11:57 ` Ævar Arnfjörð Bjarmason [this message]
2017-12-24 14:38 ` Jeff King
2017-12-24 16:10 ` Ævar Arnfjörð Bjarmason
2017-12-24 23:08 ` Eric Wong
2017-12-25 0:17 ` Ævar Arnfjörð Bjarmason
2017-12-25 1:57 ` Eric Wong
2017-12-27 18:51 ` Junio C Hamano
2017-12-27 19:16 ` Jonathan Nieder
2017-12-27 19:21 ` Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873740s5io.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=giuseppe.bilotta@gmail.com \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).