git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Todd Zullinger <tmz@pobox.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Ondřej Pohořelský" <opohorel@redhat.com>
Subject: Re: [PATCH v3 1/2] perl: bump the required Perl version to 5.8.1 from 5.8.0
Date: Thu, 16 Nov 2023 15:16:18 -0500	[thread overview]
Message-ID: <20231116201618.GB1146561@coredump.intra.peff.net> (raw)
In-Reply-To: <20231116193014.470420-2-tmz@pobox.com>

On Thu, Nov 16, 2023 at 02:30:10PM -0500, Todd Zullinger wrote:

> The following commit will make use of a Getopt::Long feature which is
> only present in Perl >= 5.8.1.  Document that as the minimum version we
> support.
> 
> Many of our Perl scripts will continue to run with 5.8.0 but this change
> allows us to adjust them as needed without breaking any promises to our
> users.
> 
> The Perl requirement was last changed in d48b284183 (perl: bump the
> required Perl version to 5.8 from 5.6.[21], 2010-09-24).  At that time,
> 5.8.0 was 8 years old.  It is now over 21 years old.

Thanks, IMHO this is long overdue. You mentioned 5.10 elsewhere in the
thread, and it came up recently in a discussion (it would allow the use
of "//" for defined-or). So we could perhaps go a bit farther. But I am
also fine with 5.8.1 for now, if that is all it takes for this fix (and
I expect the chance that it causes a problem for anybody to be close to
zero).

> Signed-off-by: Todd Zullinger <tmz@pobox.com>
> ---
> I debated changing all the 'use 5.008;' lines here, as most don't
> actually require a newer Perl, but the previous bump did the same.
> 
> I can see the merit in either direction.
> 
> Changing it allows future contributors to be confident in relying on
> 5.8.1 features.
> 
> Not changing it allows anyone stuck on 5.8.0 to continue using the perl
> scripts which don't actually require 5.8.1.

Yeah, I can see both sides of the argument. I think I'd err on the side
of bumping (as you did here). That lets somebody who will be affected
know immediately, rather than only finding out when we randomly depend
on a feature later.

All of this discussion could likewise go in the commit message. :)

> Tangentially, the Perl docs for 'use' function recommend against the
> 5.008001 form[1]:
> 
>     Specifying VERSION as a numeric argument of the form 5.024001 should
>     generally be avoided as older less readable syntax compared to
>     v5.24.1. Before perl 5.8.0 released in 2002 the more verbose numeric
>     form was the only supported syntax, which is why you might see it in
>     older code.
> 
>         use v5.24.1;    # compile time version check
>         use 5.24.1;     # ditto
>         use 5.024_001;  # ditto; older syntax compatible with perl 5.6
> 
> I'm not enough of a Perl coder to have a strong preference or desire to
> push for such a change, but I thought it was worth mentioning in case
> others wonder why we're using the 5.008001 form.

I doubt it matters too much either way. I suspect at the time we moved
to v5.8 the nicer syntax was still pretty new (having only been
introduced by v5.6, which we were moving off of) and that older versions
of perl might not give as nice a message when they see it. But given
that 5.6 is now 23 years old, we can probably assume nobody will use it
(or at least they will be accustomed to whatever ugly message it
produces).

But IMHO that should be done as a separate patch anyway.

-Peff


  reply	other threads:[~2023-11-16 20:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 16:38 [PATCH] send-email: avoid duplicate specification warnings Todd Zullinger
2023-11-14 17:32 ` Junio C Hamano
2023-11-14 20:00 ` Jeff King
2023-11-14 20:59   ` Todd Zullinger
2023-11-15  0:48     ` Junio C Hamano
2023-11-15 17:39       ` [RFC PATCH v2 0/2] " Todd Zullinger
2023-11-15 17:39         ` [RFC PATCH v2 1/2] " Todd Zullinger
2023-11-16  4:58           ` Junio C Hamano
2023-11-16 19:30             ` [PATCH v3 0/2] " Todd Zullinger
2023-11-16 19:30               ` [PATCH v3 1/2] perl: bump the required Perl version to 5.8.1 from 5.8.0 Todd Zullinger
2023-11-16 20:16                 ` Jeff King [this message]
2023-11-16 19:30               ` [PATCH v3 2/2] send-email: avoid duplicate specification warnings Todd Zullinger
2023-11-16 22:32               ` [PATCH v3 0/2] " Junio C Hamano
2023-11-15 17:39         ` [RFC PATCH v2 2/2] send-email: remove stray characters from usage Todd Zullinger
2023-11-16  4:59           ` Junio C Hamano
2023-11-16 19:36             ` [PATCH] " Todd Zullinger

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231116201618.GB1146561@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=opohorel@redhat.com \
    --cc=tmz@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).