| Message ID | 20241010235621.738239-13-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Update versions of libcurl and Perl | expand |
On Thu, Oct 10, 2024 at 11:56:20PM +0000, brian m. carlson wrote: >Update the INSTALL file to reflect our new dependency requirement. > any particular reason not to squash this into the parent commit? i see how the separation makes sense for the libcurl sub-series, but that doesn't seem applicable here. regarding the actual `use` statements, you could make them somewhat more legible by using 'v5.26' as the version number. another aspect to consider is that the statement doesn't just specify the minimal version, but also subtly changes behavior. for example, the `use strict;` statements become redundant. cf. https://perldoc.perl.org/functions/use#use-VERSION lastly, it would be nice to update the build systems to reflect the version requirements. though the only pre-existing version check i found is the libcurl one in contrib/buildsystems/CMakeLists.txt.
On 2024-10-11 at 09:38:38, Oswald Buddenhagen wrote: > On Thu, Oct 10, 2024 at 11:56:20PM +0000, brian m. carlson wrote: > > Update the INSTALL file to reflect our new dependency requirement. > > > any particular reason not to squash this into the parent commit? > i see how the separation makes sense for the libcurl sub-series, but > that doesn't seem applicable here. Sure, I can do that. > regarding the actual `use` statements, you could make them somewhat more > legible by using 'v5.26' as the version number. > > another aspect to consider is that the statement doesn't just specify > the minimal version, but also subtly changes behavior. for example, the > `use strict;` statements become redundant. > > cf. https://perldoc.perl.org/functions/use#use-VERSION Yes, I'll change that to a require v5.26 instead, since my goal isn't to change the behaviour. > lastly, it would be nice to update the build systems to reflect the > version requirements. though the only pre-existing version check i found > is the libcurl one in contrib/buildsystems/CMakeLists.txt. I don't build with cmake, so I can't speak to the requirements for it. It doesn't actually work on Unix as far as I know, and I don't run Windows at all.
diff --git a/INSTALL b/INSTALL index 6e0321ff0e..54d7528f9e 100644 --- a/INSTALL +++ b/INSTALL @@ -119,7 +119,7 @@ Issues of note: - A POSIX-compliant shell is required to run some scripts needed for everyday use (e.g. "bisect", "request-pull"). - - "Perl" version 5.8.1 or later is needed to use some of the + - "Perl" version 5.26.0 or later is needed to use some of the features (e.g. sending patches using "git send-email", interacting with svn repositories with "git svn"). If you can live without these, use NO_PERL. Note that recent releases of
Our platform support policy states that we require "versions of dependencies which are generally accepted as stable and supportable, e.g., in line with the version used by other long-term-support distributions". Of Debian, Ubuntu, RHEL, and SLES, the four most common distributions that provide LTS versions, the version with mainstream long-term security support with the oldest Perl is 5.26.0 in SLES 15.6. This is a major upgrade, since Perl 5.8.1, according to the Perl documentation, was released in September of 2003. It brings a lot of new features that we can choose to use, such as s///r to return the modified string, the postderef functionality, and subroutine signatures, although the latter was still considered experimental until 5.36. Update the INSTALL file to reflect our new dependency requirement. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- INSTALL | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)