[RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Ævar Arnfjörð Bjarmason]

In late 2010 I bumped our perl version dependency from 5.6.* to
5.8.0[1]. Git had been failing for a while on <5.8, and it was
suspected that nobody cared enough to keep using it, which turned out
to be true.

Follow that up with bumping the dependency to 5.10.0. The 5.8.0
release was released in 2002, and the 5.10.0 release just turned 10
years old[2].

This is similar to Jeff King's jk/drop-ancient-curl series in that
we're dropping perl releases that are rarely tested anymore, however
unlike those patches git still works on e.g. 5.8.8 (I couldn't build
anything older).

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].

1. d48b284183 ("perl: bump the required Perl version to 5.8 from
   5.6.[21]", 2010-09-24)

2. "perldoc perlhist" (https://metacpan.org/pod/distribution/perl/pod/perlhist.pod)

3. "perldoc perl5100delta" (https://metacpan.org/pod/distribution/perl/pod/perl5100delta.pod)

3. http://www.cpan.org/ports/binaries.html

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

RFC because this'll need to be adjusted for my cooking Makefile.PL
changes, and because the patch is obviously "correct", so the question
is "do we want to do this". Discuss.

 contrib/diff-highlight/DiffHighlight.pm | 2 +-
 contrib/examples/git-difftool.perl      | 2 +-
 contrib/mw-to-git/Git/Mediawiki.pm      | 2 +-
 git-add--interactive.perl               | 2 +-
 git-archimport.perl                     | 2 +-
 git-cvsexportcommit.perl                | 2 +-
 git-cvsimport.perl                      | 2 +-
 git-cvsserver.perl                      | 2 +-
 git-send-email.perl                     | 2 +-
 git-svn.perl                            | 2 +-
 gitweb/gitweb.perl                      | 2 +-
 perl/Git.pm                             | 2 +-
 perl/Git/I18N.pm                        | 2 +-
 perl/Git/Packet.pm                      | 2 +-
 t/t0021/rot13-filter.pl                 | 2 +-
 t/t0202/test.pl                         | 2 +-
 t/t9000/test.pl                         | 2 +-
 t/t9700/test.pl                         | 2 +-
 t/test-terminal.perl                    | 2 +-
 19 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/contrib/diff-highlight/DiffHighlight.pm b/contrib/diff-highlight/DiffHighlight.pm
index 663992e530..21fe5d424f 100644
--- a/contrib/diff-highlight/DiffHighlight.pm
+++ b/contrib/diff-highlight/DiffHighlight.pm
@@ -1,6 +1,6 @@
 package DiffHighlight;
 
-use 5.008;
+use v5.10.0;
 use warnings FATAL => 'all';
 use strict;
 
diff --git a/contrib/examples/git-difftool.perl b/contrib/examples/git-difftool.perl
index df59bdfe97..13c44846a8 100755
--- a/contrib/examples/git-difftool.perl
+++ b/contrib/examples/git-difftool.perl
@@ -10,7 +10,7 @@
 #
 # Any arguments that are unknown to this script are forwarded to 'git diff'.
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Error qw(:try);
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm b/contrib/mw-to-git/Git/Mediawiki.pm
index 917d9e2d32..5b620b8425 100644
--- a/contrib/mw-to-git/Git/Mediawiki.pm
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -1,6 +1,6 @@
 package Git::Mediawiki;
 
-use 5.008;
+use v5.10.0;
 use strict;
 use POSIX;
 use Git;
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 28b325d754..b59c9eaf30 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Git qw(unquote_path);
diff --git a/git-archimport.perl b/git-archimport.perl
index b7c173c345..7d13f7ef16 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -54,7 +54,7 @@ and can contain multiple, unrelated branches.
 
 =cut
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Getopt::Std;
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02da95..c50d981208 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Getopt::Std;
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 36929921ea..7d4dd07d35 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -13,7 +13,7 @@
 # The head revision is on branch "origin" by default.
 # You can change that with the '-o' option.
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Getopt::Long;
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ae1044273d..ddb423dbc2 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -15,7 +15,7 @@
 ####
 ####
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use bytes;
diff --git a/git-send-email.perl b/git-send-email.perl
index edcc6d3469..3f162b6bae 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -16,7 +16,7 @@
 #    and second line is the subject of the message.
 #
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use POSIX qw/strftime/;
diff --git a/git-svn.perl b/git-svn.perl
index d2404184ba..c50ceab533 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 # Copyright (C) 2006, Eric Wong <normalperson@yhbt.net>
 # License: GPL v2 or later
-use 5.008;
+use v5.10.0;
 use warnings;
 use strict;
 use vars qw/	$AUTHOR $VERSION
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2417057f2b..25178a31f7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -7,7 +7,7 @@
 #
 # This program is licensed under the GPLv2
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 # handle ACL in file access tests
diff --git a/perl/Git.pm b/perl/Git.pm
index ffa09ace92..768653f2a6 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -7,7 +7,7 @@ Git - Perl interface to the Git version control system
 
 package Git;
 
-use 5.008;
+use v5.10.0;
 use strict;
 
 
diff --git a/perl/Git/I18N.pm b/perl/Git/I18N.pm
index 836a5c2382..1d4dce687f 100644
--- a/perl/Git/I18N.pm
+++ b/perl/Git/I18N.pm
@@ -1,5 +1,5 @@
 package Git::I18N;
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 BEGIN {
diff --git a/perl/Git/Packet.pm b/perl/Git/Packet.pm
index b75738bed4..4a1491a1dd 100644
--- a/perl/Git/Packet.pm
+++ b/perl/Git/Packet.pm
@@ -1,5 +1,5 @@
 package Git::Packet;
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 BEGIN {
diff --git a/t/t0021/rot13-filter.pl b/t/t0021/rot13-filter.pl
index f1678851de..be6177f564 100644
--- a/t/t0021/rot13-filter.pl
+++ b/t/t0021/rot13-filter.pl
@@ -30,7 +30,7 @@
 #     to the "list_available_blobs" response.
 #
 
-use 5.008;
+use v5.10.0;
 use lib (split(/:/, $ENV{GITPERLLIB}));
 use strict;
 use warnings;
diff --git a/t/t0202/test.pl b/t/t0202/test.pl
index 2cbf7b9590..3c122ccec0 100755
--- a/t/t0202/test.pl
+++ b/t/t0202/test.pl
@@ -1,5 +1,5 @@
 #!/usr/bin/perl
-use 5.008;
+use v5.10.0;
 use lib (split(/:/, $ENV{GITPERLLIB}));
 use strict;
 use warnings;
diff --git a/t/t9000/test.pl b/t/t9000/test.pl
index dfeaa9c655..1ac3566c1f 100755
--- a/t/t9000/test.pl
+++ b/t/t9000/test.pl
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 use lib (split(/:/, $ENV{GITPERLLIB}));
 
-use 5.008;
+use v5.10.0;
 use warnings;
 use strict;
 
diff --git a/t/t9700/test.pl b/t/t9700/test.pl
index 34cd01366f..f1d46465b5 100755
--- a/t/t9700/test.pl
+++ b/t/t9700/test.pl
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 use lib (split(/:/, $ENV{GITPERLLIB}));
 
-use 5.008;
+use v5.10.0;
 use warnings;
 use strict;
 
diff --git a/t/test-terminal.perl b/t/test-terminal.perl
index 46bf618479..fab093a957 100755
--- a/t/test-terminal.perl
+++ b/t/test-terminal.perl
@@ -1,5 +1,5 @@
 #!/usr/bin/perl
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use IO::Pty;
-- 
2.15.1.424.g9478a66081

RE: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Randall S. Becker]

On December 23, 2017 12:44 PM,  Ævar Arnfjörð Bjarmason wrote:
> 
> In late 2010 I bumped our perl version dependency from 5.6.* to 5.8.0[1]. Git
> had been failing for a while on <5.8, and it was suspected that nobody cared
> enough to keep using it, which turned out to be true.
> 
> Follow that up with bumping the dependency to 5.10.0. The 5.8.0 release
> was released in 2002, and the 5.10.0 release just turned 10 years old[2].

The git HPE NonStop NSE/NSX ports that I maintain has Perl 5.22 generally available, so no objections here. Ours is just a CPAN dependency concern as previously discussed. 😊

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

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.

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.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Ævar Arnfjörð Bjarmason]

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

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Jeff King]

On Sat, Dec 23, 2017 at 05:44:00PM +0000, Ævar Arnfjörð Bjarmason wrote:

> This is similar to Jeff King's jk/drop-ancient-curl series in that
> we're dropping perl releases that are rarely tested anymore, however
> unlike those patches git still works on e.g. 5.8.8 (I couldn't build
> anything older).

Heh, I'm not sure if those are the best prior art to justify this, since
I stopped posting them after getting complaints (though I'll admit I was
considering re-posting them since AFAICT nobody has stepped up to fix
the breakage after many months).

This may be more like the recent C99 weather-balloon patches, in that
we're not using the new features yet, but want to see if anybody screams
at this first change.

> 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].

As far as this actual perl change goes, I don't have a strong opinion. I
agree it would be nice to eventually move forward, and your reasoning
about what constitutes "old" seems sane. But we also don't write much
perl in this project these days, and I don't see a lack of modern perl
features causing a lot of headaches.

-Peff

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Ævar Arnfjörð Bjarmason]

On Sun, Dec 24 2017, Jeff King jotted:

> On Sat, Dec 23, 2017 at 05:44:00PM +0000, Ævar Arnfjörð Bjarmason wrote:
>
>> This is similar to Jeff King's jk/drop-ancient-curl series in that
>> we're dropping perl releases that are rarely tested anymore, however
>> unlike those patches git still works on e.g. 5.8.8 (I couldn't build
>> anything older).
>
> Heh, I'm not sure if those are the best prior art to justify this, since
> I stopped posting them after getting complaints (though I'll admit I was
> considering re-posting them since AFAICT nobody has stepped up to fix
> the breakage after many months).

Less of a justification, more of a "this is going to be a similar sort
of dumpster fire" :)

> This may be more like the recent C99 weather-balloon patches, in that
> we're not using the new features yet, but want to see if anybody screams
> at this first change.
>
>> 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].
>
> As far as this actual perl change goes, I don't have a strong opinion. I
> agree it would be nice to eventually move forward, and your reasoning
> about what constitutes "old" seems sane. But we also don't write much
> perl in this project these days, and I don't see a lack of modern perl
> features causing a lot of headaches.

Yes, unlike with the curl patches it's not a big PITA to maintain
compatibility with 5.8, it would just be easier to write new code &
maintain old code and not have to be on guard about not using features
one takes for grantend, and maintain compatibility with 5.8 versions of
core modules.

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Eric Wong]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Sun, Dec 24 2017, Jeff King jotted:
> > As far as this actual perl change goes, I don't have a strong opinion. I
> > agree it would be nice to eventually move forward, and your reasoning
> > about what constitutes "old" seems sane. But we also don't write much
> > perl in this project these days, and I don't see a lack of modern perl
> > features causing a lot of headaches.

Agreed.

> Yes, unlike with the curl patches it's not a big PITA to maintain
> compatibility with 5.8, it would just be easier to write new code &
> maintain old code and not have to be on guard about not using features
> one takes for grantend, and maintain compatibility with 5.8 versions of
> core modules.

As one of the more frequent Perl users here (even outside of
git.git), I never considered using 5.10+ features at all until
now.  Maybe 5.8 compatibility is just too ingrained into me and
much of the stuff I work on is old and ancient(*).

That said, reading perl5100delta does reveal features such as
defined-or and given/when that I might find useful; but I'm also
not going to replace existing code to use new features unless
there is a clear improvement.

If there's new code people are developing using 5.10; I would
not object at all.  Otherwise, I don't see compatibility with
5.8 hurts more than it helps.

Maybe we change our docs to say we welcome 5.10 features for new
code, but I'm against changing things for the sake of change.


(*) Like this 32-bit laptop from 2005.  Only problem I have with
    it is the noisy fan.

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Ævar Arnfjörð Bjarmason]

On Sun, Dec 24 2017, Eric Wong jotted:

[Removed Petr Baudis <pasky@suse.cz> from CC, his suse.cz E-Mail address
is bouncing]

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> On Sun, Dec 24 2017, Jeff King jotted:
>> > As far as this actual perl change goes, I don't have a strong opinion. I
>> > agree it would be nice to eventually move forward, and your reasoning
>> > about what constitutes "old" seems sane. But we also don't write much
>> > perl in this project these days, and I don't see a lack of modern perl
>> > features causing a lot of headaches.
>
> Agreed.
>
>> Yes, unlike with the curl patches it's not a big PITA to maintain
>> compatibility with 5.8, it would just be easier to write new code &
>> maintain old code and not have to be on guard about not using features
>> one takes for grantend, and maintain compatibility with 5.8 versions of
>> core modules.
>
> As one of the more frequent Perl users here (even outside of
> git.git), I never considered using 5.10+ features at all until
> now.  Maybe 5.8 compatibility is just too ingrained into me and
> much of the stuff I work on is old and ancient(*).
>
> That said, reading perl5100delta does reveal features such as
> defined-or and given/when that I might find useful; but I'm also
> not going to replace existing code to use new features unless
> there is a clear improvement.
>
> If there's new code people are developing using 5.10; I would
> not object at all.  Otherwise, I don't see compatibility with
> 5.8 hurts more than it helps.

Aside from whatever we do here, I don't think this would be a good idea
& would introduce a lot of confusion for packagers, e.g. requiring one
version of OpenSSL for hashing, but another one for "imap-send", or one
version of curl for "push", and another for "imap-send".

I think for any given external dependency of git.git it makes sense to
just pick a version, not say that this script requires perl so-and-so,
this one python so-and-so, or curl/openssl so-and-so etc.

> Maybe we change our docs to say we welcome 5.10 features for new
> code, but I'm against changing things for the sake of change.

I should have mentioned this in the commit message, but for me it's
mainly that whenever I patch the Git perl code there's no easy way to
test if it works on a currently supported release, 5.8.* doesn't even
build anymore on a modern compiler without monkeypatching with
Devel::PatchPerl (and then only some subreleases).

I think it's reasonable for us, in general, to at some point pass the
buck in maintaining dependencies to people who want to still build on
ancient versions. And not just for perl, but e.g. curl too, which is
something I commented on at some length in <874ltg2tvo.fsf@gmail.com>
(https://public-inbox.org/git/874ltg2tvo.fsf@gmail.com/). I.e. if you
need to really build the latest git on RHEL 5 with all bells & whistles
you also build perl.

It's not just change for the sake of change, there's a high cognitive
overhead in trying to write code against the last 15 years of some
software as opposed to "just" 10 years (which is already bad enough).

Of course any one change isn't going to be what makes it or breaks it,
so it's hard to make the argument in terms of "I must use this new
feature here". But if that was the standard we were applying we'd still
be supporting perl 5.6[1].

1. If it hadn't turned out that it was broken for years because of using
  a new feature, see d48b284183 ("perl: bump the required Perl version
  to 5.8 from 5.6.[21]", 2010-09-24)

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Eric Wong]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> I think for any given external dependency of git.git it makes sense to
> just pick a version, not say that this script requires perl so-and-so,
> this one python so-and-so, or curl/openssl so-and-so etc.

Agreed.  Any version support changes should be tree-wide.

> On Sun, Dec 24 2017, Eric Wong jotted:
> > Maybe we change our docs to say we welcome 5.10 features for new
> > code, but I'm against changing things for the sake of change.
> 
> I should have mentioned this in the commit message, but for me it's
> mainly that whenever I patch the Git perl code there's no easy way to
> test if it works on a currently supported release, 5.8.* doesn't even
> build anymore on a modern compiler without monkeypatching with
> Devel::PatchPerl (and then only some subreleases).

Fair enough, I haven't run 5.8 in a while, either.  One concern
I have is it makes reviewing more difficult as the language gets
bigger and (even more) unfamiliar constructs pop up.  This is
probably more important for git as most of us are not dedicated
Perl hackers.

What mostly bugs me about this is going from:

	"we'll accept patches to keep your old system working"

 to:

	"your software is too old, upgrade or go away"

> I think it's reasonable for us, in general, to at some point pass the
> buck in maintaining dependencies to people who want to still build on
> ancient versions. And not just for perl, but e.g. curl too, which is
> something I commented on at some length in <874ltg2tvo.fsf@gmail.com>
> (https://public-inbox.org/git/874ltg2tvo.fsf@gmail.com/). I.e. if you
> need to really build the latest git on RHEL 5 with all bells & whistles
> you also build perl.

I don't disagree; but curl is different animal in that it was a
maintenance burden for us.

> It's not just change for the sake of change, there's a high cognitive
> overhead in trying to write code against the last 15 years of some
> software as opposed to "just" 10 years (which is already bad enough).

Heh, I was making the same point for staying with older versions
since it's less cognitive overhead for me (and presumably others)
to use a smaller featureset.

> Of course any one change isn't going to be what makes it or breaks it,
> so it's hard to make the argument in terms of "I must use this new
> feature here". But if that was the standard we were applying we'd still
> be supporting perl 5.6[1].

Right, if there's a compelling case to depend on 5.10 then I'm
all for it.  I don't think we've hit a breaking point like
we did with 5.8, yet.

> 1. If it hadn't turned out that it was broken for years because of using
>   a new feature, see d48b284183 ("perl: bump the required Perl version
>   to 5.8 from 5.6.[21]", 2010-09-24)

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Junio C Hamano]

Eric Wong <e@80x24.org> writes:

> Fair enough, I haven't run 5.8 in a while, either.  One concern
> I have is it makes reviewing more difficult as the language gets
> bigger and (even more) unfamiliar constructs pop up.  This is
> probably more important for git as most of us are not dedicated
> Perl hackers.

Yes, but that cuts both ways.  When we do get a less amateur Perl
folks who contribute and review, they are more and more likely to be
fluent in modern versions of Perl than the ancient ones some of us
who learned the tongue long time ago are familiar with.  Telling
them to limit themselves to what is also available in ancient
versions is a burden that is backwards.

So

> What mostly bugs me about this is going from:
>
> 	"we'll accept patches to keep your old system working"
>
>  to:
>
> 	"your software is too old, upgrade or go away"

is something we need to be able to say at some point.

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Jonathan Nieder]

Hi,

Ævar Arnfjörð Bjarmason wrote:

> This is similar to Jeff King's jk/drop-ancient-curl series in that
> we're dropping perl releases that are rarely tested anymore, however
> unlike those patches git still works on e.g. 5.8.8 (I couldn't build
> anything older).

FWIW I think this is a good change.  If someone is affected and offers
help with keeping git working well with older perl (e.g. setting up CI
for us) then we can keep supporting it, but it seems more likely to me
that there will just not be anyone affected.

And being able to assume a newer baseline perl version seems
beneficial both from a security point of view and from a developer
experience pov.

Some minor nits:

[...]
>  contrib/diff-highlight/DiffHighlight.pm | 2 +-
>  contrib/examples/git-difftool.perl      | 2 +-
>  contrib/mw-to-git/Git/Mediawiki.pm      | 2 +-

I'm less opinionated about these.  They're already using the same perl
baseline as the rest of git, so I suppose it's good to keep them
consistent, but if any of them gives you trouble then I think you can
just ignore it and let the relevant contrib maintainer take care of
it. :)

[...]
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -1,6 +1,6 @@
>  #!/usr/bin/perl
>  
> -use 5.008;
> +use v5.10.0;

As brian carlson mentioned, 'use 5.010' would produce a clearer error
message on ancient perl, which could result in happier users on
ancient platforms or clearer bug reports.

That said, I don't have a strong opinion there.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Jonathan Nieder]

Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:

>> This is similar to Jeff King's jk/drop-ancient-curl series in that
>> we're dropping perl releases that are rarely tested anymore, however
>> unlike those patches git still works on e.g. 5.8.8 (I couldn't build
>> anything older).
[...]
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

One caveat I forgot: please also update the INSTALL file:

 - Git is reasonably self-sufficient, but does depend on a few external
   programs and libraries.  Git can be used without most of them by adding
   the approriate "NO_<LIBRARY>=YesPlease" to the make command line or
   config.mak file.
[...]
        - "Perl" version 5.8 or later is needed to use some of the

Thanks again,
Jonathan