Re: Mop-up from Test::More version change patch
On 23.11.21 18:03, Tom Lane wrote: 0002 is written to apply to v14 and earlier, and what it wants to do is back-patch the effects of 405f32fc4, so that the minimum Test::More version is 0.98 in all branches. The thought here is that (1) somebody is likely to want to back-patch a test involving Test::More::subtest before too long; (2) we have zero coverage for older Test::More versions anyway, now that all buildfarm members have been updated to work with HEAD. The backpatching argument is a little off-target, I think. The purpose of subtests is so that wrappers like command_fails_like() count only as one test on the outside, instead of however many checks it runs internally. There is no use in using the subtest feature in a top-level test one might add, say in response to a bugfix. So the only reason this might become relevant is if someone were to backpatch new test infrastructure, which seems rare and in most cases would probably require additional portability and backpatching care. And even then, you still need to adjust the test count at the top of the file individually in each branch, because the total number of tests will probably be different. In my mind, the subtests feature is useful during new development, where you write a bunch of new tests and want to set the total test count by eyeballing what you just wrote instead of having to run test cycles and react to the complaints. But it won't be useful for patching tests into existing files. In summary, I would leave it alone.
Re: Mop-up from Test::More version change patch
On Tue, Nov 23, 2021 at 12:03:05PM -0500, Tom Lane wrote: > Attached are a couple of patches I propose in the wake of commit > 405f32fc4 (Require version 0.98 of Test::More for TAP tests). > > 0001 responds to the failure we saw on buildfarm member wrasse [1] > where, despite configure having carefully checked for Test::More > being >= 0.98, actual tests failed with > Test::More version 0.98 required--this is only version 0.92 at > /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/../pgsql/src/test/perl/PostgreSQL/Test/Utils.pm > line 63. > The reason is that wrasse was choosing "prove" from a different > Perl installation than "perl", as a result of its configuration > having set PERL to a nondefault place but doing nothing about PROVE. > > We already installed a couple of mitigations for that: > (a) as of c4fe3199a, configure checks "prove" not "perl" for > appropriate module versions; > (b) Noah has modified wrasse's configuration to set PROVE. > But I'm of the opinion that (b) should not be necessary. > If you set PERL then it's highly likely that you want to use > "prove" from the same installation. My regular development system is a counterexample. It uses system Perl, but it has a newer "prove" from CPAN: $ grep -E '(PERL|PROVE)' config.status S["PROVE"]="/home/nm/sw/cpan/bin/prove" S["PERL"]="/usr/bin/perl" The patch sends it back to using the system "prove": S["PROVE"]="/usr/bin/prove" S["PERL"]="/usr/bin/perl" I could, of course, override that. But with so little evidence about systems helped by the proposed change, I'm now -1.0 on it. > 0002 is written to apply to v14 and earlier, and what it wants > to do is back-patch the effects of 405f32fc4, so that the > minimum Test::More version is 0.98 in all branches. The thought > here is that (1) somebody is likely to want to back-patch a > test involving Test::More::subtest before too long; (2) we have > zero coverage for older Test::More versions anyway, now that > all buildfarm members have been updated to work with HEAD. wrasse v10..v14 is testing older Test::More, so coverage persists. However, I am okay with this change.
Re: Mop-up from Test::More version change patch
Andrew Dunstan writes: > On 11/23/21 12:03, Tom Lane wrote: >> If you set PERL then it's highly likely that you want to use >> "prove" from the same installation. So 0001 modifies configure >> to first check for an executable "prove" in the same directory >> as $PERL. If that's not what you want then you should override >> it by setting PROVE explicitly. > Do we really have much of an issue left to solve given c4fe3199a? It > feels a bit like a solution in search of a problem. We don't absolutely have to do this, agreed. But I think the current behavior fails to satisfy the POLA. As I remarked in the other thread, I'm worried about somebody wasting time trying to identify why their TAP test isn't behaving the way it does when they invoke the code under the perl they think they're using. regards, tom lane
Re: Mop-up from Test::More version change patch
On 11/23/21 12:03, Tom Lane wrote: > [ moving thread to -hackers for a bit more visibility ] > > Attached are a couple of patches I propose in the wake of commit > 405f32fc4 (Require version 0.98 of Test::More for TAP tests). > > 0001 responds to the failure we saw on buildfarm member wrasse [1] > where, despite configure having carefully checked for Test::More > being >= 0.98, actual tests failed with > Test::More version 0.98 required--this is only version 0.92 at > /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/../pgsql/src/test/perl/PostgreSQL/Test/Utils.pm > line 63. > The reason is that wrasse was choosing "prove" from a different > Perl installation than "perl", as a result of its configuration > having set PERL to a nondefault place but doing nothing about PROVE. > > We already installed a couple of mitigations for that: > (a) as of c4fe3199a, configure checks "prove" not "perl" for > appropriate module versions; > (b) Noah has modified wrasse's configuration to set PROVE. > But I'm of the opinion that (b) should not be necessary. > If you set PERL then it's highly likely that you want to use > "prove" from the same installation. So 0001 modifies configure > to first check for an executable "prove" in the same directory > as $PERL. If that's not what you want then you should override > it by setting PROVE explicitly. > > Since this is mainly meant to prevent an easy-to-make error in > setting up buildfarm configurations, we should back-patch it. Do we really have much of an issue left to solve given c4fe3199a? It feels a bit like a solution in search of a problem. > > 0002 is written to apply to v14 and earlier, and what it wants > to do is back-patch the effects of 405f32fc4, so that the > minimum Test::More version is 0.98 in all branches. The thought > here is that (1) somebody is likely to want to back-patch a > test involving Test::More::subtest before too long; (2) we have > zero coverage for older Test::More versions anyway, now that > all buildfarm members have been updated to work with HEAD. > This one seems like a good idea. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Mop-up from Test::More version change patch
[ moving thread to -hackers for a bit more visibility ]
Attached are a couple of patches I propose in the wake of commit
405f32fc4 (Require version 0.98 of Test::More for TAP tests).
0001 responds to the failure we saw on buildfarm member wrasse [1]
where, despite configure having carefully checked for Test::More
being >= 0.98, actual tests failed with
Test::More version 0.98 required--this is only version 0.92 at
/export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/../pgsql/src/test/perl/PostgreSQL/Test/Utils.pm
line 63.
The reason is that wrasse was choosing "prove" from a different
Perl installation than "perl", as a result of its configuration
having set PERL to a nondefault place but doing nothing about PROVE.
We already installed a couple of mitigations for that:
(a) as of c4fe3199a, configure checks "prove" not "perl" for
appropriate module versions;
(b) Noah has modified wrasse's configuration to set PROVE.
But I'm of the opinion that (b) should not be necessary.
If you set PERL then it's highly likely that you want to use
"prove" from the same installation. So 0001 modifies configure
to first check for an executable "prove" in the same directory
as $PERL. If that's not what you want then you should override
it by setting PROVE explicitly.
Since this is mainly meant to prevent an easy-to-make error in
setting up buildfarm configurations, we should back-patch it.
0002 is written to apply to v14 and earlier, and what it wants
to do is back-patch the effects of 405f32fc4, so that the
minimum Test::More version is 0.98 in all branches. The thought
here is that (1) somebody is likely to want to back-patch a
test involving Test::More::subtest before too long; (2) we have
zero coverage for older Test::More versions anyway, now that
all buildfarm members have been updated to work with HEAD.
Any objections?
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse=2021-11-20%2022%3A58%3A17
diff --git a/configure b/configure
index 896b781473..a86a31fb42 100755
--- a/configure
+++ b/configure
@@ -19411,7 +19411,17 @@ fi
#
if test "$enable_tap_tests" = yes; then
# Make sure we know where prove is.
+ # Prefer a prove located in the same directory as $PERL,
+ # otherwise search $PATH.
if test -z "$PROVE"; then
+if test -x "`dirname "$PERL"`/prove"; then
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for prove" >&5
+$as_echo_n "checking for prove... " >&6; }
+ PROVE="`dirname "$PERL"`/prove"
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $PROVE" >&5
+$as_echo "$PROVE" >&6; }
+else
+ if test -z "$PROVE"; then
for ac_prog in prove
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
@@ -19465,8 +19475,10 @@ $as_echo_n "checking for PROVE... " >&6; }
$as_echo "$PROVE" >&6; }
fi
- if test -z "$PROVE"; then
-as_fn_error $? "prove not found" "$LINENO" 5
+ if test -z "$PROVE"; then
+as_fn_error $? "prove not found" "$LINENO" 5
+ fi
+fi
fi
# Check for necessary Perl modules. You might think we should use
# AX_PROG_PERL_MODULES here, but prove might be part of a different Perl
diff --git a/configure.ac b/configure.ac
index b50130b323..98cd5ae12e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2378,9 +2378,19 @@ PGAC_PATH_PROGS(DBTOEPUB, dbtoepub)
#
if test "$enable_tap_tests" = yes; then
# Make sure we know where prove is.
- PGAC_PATH_PROGS(PROVE, prove)
+ # Prefer a prove located in the same directory as $PERL,
+ # otherwise search $PATH.
if test -z "$PROVE"; then
-AC_MSG_ERROR([prove not found])
+if test -x "`dirname "$PERL"`/prove"; then
+ AC_MSG_CHECKING(for prove)
+ PROVE="`dirname "$PERL"`/prove"
+ AC_MSG_RESULT([$PROVE])
+else
+ PGAC_PATH_PROGS(PROVE, prove)
+ if test -z "$PROVE"; then
+AC_MSG_ERROR([prove not found])
+ fi
+fi
fi
# Check for necessary Perl modules. You might think we should use
# AX_PROG_PERL_MODULES here, but prove might be part of a different Perl
diff --git a/config/check_modules.pl b/config/check_modules.pl
index 399ac5e3b6..cc0a7ab0e7 100644
--- a/config/check_modules.pl
+++ b/config/check_modules.pl
@@ -11,7 +11,7 @@ use IPC::Run 0.79;
# Test::More and Time::HiRes are supposed to be part of core Perl,
# but some distros omit them in a minimal installation.
-use Test::More 0.87;
+use Test::More 0.98;
use Time::HiRes 1.52;
# While here, we might as well report exactly what versions we found.
diff --git a/src/test/perl/TestLib.pm b/src/test/perl/TestLi
Re: Test::More version
On 11/20/21 11:14, Tom Lane wrote: > Andrew Dunstan writes: >> Yeah, so I think at this stage we're just waiting for you to update >> prairiedog and we can make this change. > Oh! I was intentionally waiting to do that, with the idea of verifying > that the version-detection test works ;-). I'm prepared to do it as > soon as you push an update and we see prairiedog go red. Ah, ok. Pushed. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: Test::More version
Andrew Dunstan writes: > Yeah, so I think at this stage we're just waiting for you to update > prairiedog and we can make this change. Oh! I was intentionally waiting to do that, with the idea of verifying that the version-detection test works ;-). I'm prepared to do it as soon as you push an update and we see prairiedog go red. regards, tom lane
Re: Test::More version
On 11/15/21 12:43, Tom Lane wrote: > > So, discounting prairiedog's intentionally trailing-edge installation, > the oldest stuff in the buildfarm is 0.98, of which there are five > instances belonging to four different owners. > > Based on this, I'm inclined to think we should select 0.98 as the > minimum version. Anything later would inconvenience some people. > OTOH, it doesn't look like there's any value in promising compatibility > with 0.96 instead, especially since I see a couple of subplan-related > bug fixes in 0.97 and 0.98 in Test::Simple's changelog. > > Yeah, so I think at this stage we're just waiting for you to update prairiedog and we can make this change. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: Test::More version
On 11/15/21 14:14, Tom Lane wrote: > =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes: >> Tom Lane writes: >>> Based on this, I'm inclined to think we should select 0.98 as the >>> minimum version. Anything later would inconvenience some people. >>> OTOH, it doesn't look like there's any value in promising compatibility >>> with 0.96 instead, especially since I see a couple of subplan-related >>> bug fixes in 0.97 and 0.98 in Test::Simple's changelog. >> FWIW, here's a list of Test::More versions shipped with various Perl >> releases. Since v5.12.0, the version does not change in minor releases. >> ... >> v5.12.00.94 >> v5.14.00.98 > Ah-hah, that's a good way to think about it too. There's surely > little reason in worrying about a module version that did not ship > in any Perl release, because what 99.9% of people will have is what > shipped with their Perl release. > > And newer versions of Test::Simple/Test::More still work with very old versions of perl. jacana runs prove with perl 5.8.8 but has Test::More 1.001014 So I agree 0.98 seems like a perfectly reasonable target. You should be able to drop a replacement on prairiedog quite simply. For jacana I just unpacked it and pointed PERL5LIB at it. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: Test::More version
Tom Lane writes: > =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes: Your MUA seems a bit MIME-deficient… >> Tom Lane writes: >>> Based on this, I'm inclined to think we should select 0.98 as the >>> minimum version. Anything later would inconvenience some people. >>> OTOH, it doesn't look like there's any value in promising compatibility >>> with 0.96 instead, especially since I see a couple of subplan-related >>> bug fixes in 0.97 and 0.98 in Test::Simple's changelog. > >> FWIW, here's a list of Test::More versions shipped with various Perl >> releases. Since v5.12.0, the version does not change in minor releases. >> ... >> v5.12.00.94 >> v5.14.00.98 > > Ah-hah, that's a good way to think about it too. There's surely > little reason in worrying about a module version that did not ship > in any Perl release, because what 99.9% of people will have is what > shipped with their Perl release. Or newer, if they ever install anything from CPAN, since many modules depend on a newer version. Some OSes even package newer versions separately in addition to the core version, which install earlier in the include path. E.g. Debian has the following versions: Debian | Perl | core | packaged 8 | 5.20.2 | 1.001002 | 1.001008 9 | 5.24.1 | 1.001014 | 1.302075 10 | 5.28.1 | 1.302133 | 1.302162 11 | 5.32.1 | 1.302175 | 1.302183 - ilmari
Re: Test::More version
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes: > Tom Lane writes: >> Based on this, I'm inclined to think we should select 0.98 as the >> minimum version. Anything later would inconvenience some people. >> OTOH, it doesn't look like there's any value in promising compatibility >> with 0.96 instead, especially since I see a couple of subplan-related >> bug fixes in 0.97 and 0.98 in Test::Simple's changelog. > FWIW, here's a list of Test::More versions shipped with various Perl > releases. Since v5.12.0, the version does not change in minor releases. > ... > v5.12.00.94 > v5.14.00.98 Ah-hah, that's a good way to think about it too. There's surely little reason in worrying about a module version that did not ship in any Perl release, because what 99.9% of people will have is what shipped with their Perl release. regards, tom lane
Re: Test::More version
Tom Lane writes: > Based on this, I'm inclined to think we should select 0.98 as the > minimum version. Anything later would inconvenience some people. > OTOH, it doesn't look like there's any value in promising compatibility > with 0.96 instead, especially since I see a couple of subplan-related > bug fixes in 0.97 and 0.98 in Test::Simple's changelog. FWIW, here's a list of Test::More versions shipped with various Perl releases. Since v5.12.0, the version does not change in minor releases. v5.8.3 0.47 v5.8.7 0.54 v5.8.8 0.62 v5.8.9 0.80 v5.10.00.72 v5.10.10.92 v5.12.00.94 v5.14.00.98 v5.16.00.98 v5.18.00.98 v5.20.01.001002 v5.22.01.001014 v5.24.01.001014 v5.26.01.302073 v5.28.01.302133 v5.30.01.302162 v5.32.01.302175 v5.34.01.302183 - ilmari
Re: Test::More version
Andrew Dunstan writes: > Thanks. pushed a slightly more robust version. I think we have enough info now to draw conclusions. There are several buildfarm animals that are running TAP tests but haven't reported since this went in. However, I don't think any of them will yield surprises: frogfish | 2021-11-10 02:24:27 | checking for perl module Test::More 0.87... ok mandrill | 2021-11-12 04:45:42 | checking for perl module Test::More 0.87... ok mereswine | 2021-11-12 09:48:49 | checking for perl module Test::More 0.87... ok sungazer | 2021-11-10 20:27:12 | checking for perl module Test::More 0.87... ok tern | 2021-11-09 05:27:38 | checking for perl module Test::More 0.87... ok topminnow | 2021-11-08 05:03:17 | checking for perl module Test::More 0.87... ok mereswine is running pretty up-to-date Debian, so that's not going to be an old version. mandrill, sungazer, and tern share the same host as hornet, which has reported using 1.302183. I cheated and looked at frogfish/topminnow's host, and it has Test::More 0.98: tgl@erpro8-fsf1:~$ perl -MTest::More -e 'print "$Test::More::VERSION\n"'; 0.98 So this should be a pretty complete summary of relevant old Test::More versions: prairiedog| 2021-11-13 12:38:32 | checking for perl module Test::More 0.87... 0.8701 lapwing | 2021-11-13 04:40:12 | checking for perl module Test::More 0.87... 0.98 prion | 2021-11-13 03:53:16 | checking for perl module Test::More 0.87... 0.98 snapper | 2021-11-13 17:27:29 | checking for perl module Test::More 0.87... 0.98 curculio | 2021-11-13 05:15:54 | checking for perl module Test::More 0.87... 1.001002 butterflyfish | 2021-11-13 06:00:29 | checking for perl module Test::More 0.87... 1.001014 There are a couple more running 1.001014, and everything else is 1.302something. So, discounting prairiedog's intentionally trailing-edge installation, the oldest stuff in the buildfarm is 0.98, of which there are five instances belonging to four different owners. Based on this, I'm inclined to think we should select 0.98 as the minimum version. Anything later would inconvenience some people. OTOH, it doesn't look like there's any value in promising compatibility with 0.96 instead, especially since I see a couple of subplan-related bug fixes in 0.97 and 0.98 in Test::Simple's changelog. regards, tom lane
Re: Test::More version
On 11/12/21 10:05, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/11/21 15:44, Tom Lane wrote: >>> Yeah ... configure is already checking those versions, so maybe we could >>> make it print them out along the way? I'd been thinking of doing exactly >>> this just for documentation purposes, so if there's a concrete need for >>> it, let's get it done. >> The attached seems to do the trick: > LGTM (by eyeball, didn't test) Thanks. pushed a slightly more robust version. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: Test::More version
Peter Eisentraut writes: > On 11.11.21 21:04, Andrew Dunstan wrote: >> But I'd really like it if we could shift the goalposts a bit and require >> 0.96. subtests would be really nice to have available. Unfortunately I >> don't have any idea what versions of Test::More are actually in use. > My initial patch for TAP tests used subtests, and IIRC that was taken > out because the Perl that comes with CentOS 6 is too old. I retired my RHEL6 installation a year ago, but I still have backups at hand (...digs...) Yeah, its Test/More.pm says $VERSION = '0.92'; so your recollection is accurate. RHEL6 has been EOL for awhile, and that specific platform isn't in the buildfarm, so it needn't constrain our decision. But it may well be that some of the older buildfarm members have similarly ancient Test::More. I await results from Andrew's patch. regards, tom lane
Re: Test::More version
Andrew Dunstan writes: > On 11/11/21 15:44, Tom Lane wrote: >> Yeah ... configure is already checking those versions, so maybe we could >> make it print them out along the way? I'd been thinking of doing exactly >> this just for documentation purposes, so if there's a concrete need for >> it, let's get it done. > The attached seems to do the trick: LGTM (by eyeball, didn't test) regards, tom lane
Re: Test::More version
On 11/11/21 15:44, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2021-Nov-11, Andrew Dunstan wrote:
>>> Perhaps we could add a line to one of the TAP tests that would spit out
>>> the version on the log?
>> Maybe have it spit out the version of *all* the modules we require
>> (which aren't all that many), not just Test::More?
> Yeah ... configure is already checking those versions, so maybe we could
> make it print them out along the way? I'd been thinking of doing exactly
> this just for documentation purposes, so if there's a concrete need for
> it, let's get it done.
>
The attached seems to do the trick:
checking for perl module IPC::Run 0.79... 20200505.0
checking for perl module Test::More 0.87... 1.302183
checking for perl module Time::HiRes 1.52... 1.9764
>
> I have no objection to updating prairiedog to whatever new minimum
> version we settle on. But if there are other buildfarm animals with
> old versions, that might be a reason not to change it.
>
>
Yeah, let's see what's actually in use and then we can decide.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/config/ax_prog_perl_modules.m4 b/config/ax_prog_perl_modules.m4
index 70b3230ebd..03c25c3ab2 100644
--- a/config/ax_prog_perl_modules.m4
+++ b/config/ax_prog_perl_modules.m4
@@ -55,12 +55,12 @@ if test "x$PERL" != x; then
AC_MSG_CHECKING(for perl module $ax_perl_module)
# Would be nice to log result here, but can't rely on autoconf internals
-$PERL -e "use $ax_perl_module; exit" > /dev/null 2>&1
+modversion=`$PERL -e "use $ax_perl_module; my \\\$x=q($ax_perl_module); \\\$x =~ s/ .*/::VERSION/; eval qq{print $\\\$x\\n}; exit;" 2>/dev/null`
if test $? -ne 0; then
AC_MSG_RESULT(no);
ax_perl_modules_failed=1
else
- AC_MSG_RESULT(ok);
+ AC_MSG_RESULT($modversion);
fi
done
diff --git a/configure b/configure
index 7d4e42dd62..d0f0f88a1b 100755
--- a/configure
+++ b/configure
@@ -19301,14 +19301,14 @@ if test "x$PERL" != x; then
$as_echo_n "checking for perl module $ax_perl_module... " >&6; }
# Would be nice to log result here, but can't rely on autoconf internals
-$PERL -e "use $ax_perl_module; exit" > /dev/null 2>&1
+modversion=`$PERL -e "use $ax_perl_module; my \\\$x=q($ax_perl_module); \\\$x =~ s/ .*/::VERSION/; eval qq{print $\\\$x\\n}; exit;" 2>/dev/null`
if test $? -ne 0; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; };
ax_perl_modules_failed=1
else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: ok" >&5
-$as_echo "ok" >&6; };
+ { $as_echo "$as_me:${as_lineno-$LINENO}: result: $modversion" >&5
+$as_echo "$modversion" >&6; };
fi
done
Re: Test::More version
On 11.11.21 21:04, Andrew Dunstan wrote: But I'd really like it if we could shift the goalposts a bit and require 0.96. subtests would be really nice to have available. Unfortunately I don't have any idea what versions of Test::More are actually in use. My initial patch for TAP tests used subtests, and IIRC that was taken out because the Perl that comes with CentOS 6 is too old.
Re: Test::More version
Alvaro Herrera writes: > On 2021-Nov-11, Andrew Dunstan wrote: >> Perhaps we could add a line to one of the TAP tests that would spit out >> the version on the log? > Maybe have it spit out the version of *all* the modules we require > (which aren't all that many), not just Test::More? Yeah ... configure is already checking those versions, so maybe we could make it print them out along the way? I'd been thinking of doing exactly this just for documentation purposes, so if there's a concrete need for it, let's get it done. Having said that, I don't think I believe that changelog entry, because prairiedog is doing just fine with $ perl -MTest::More -e 'print "$Test::More::VERSION\n"' 0.8701 I have no objection to updating prairiedog to whatever new minimum version we settle on. But if there are other buildfarm animals with old versions, that might be a reason not to change it. regards, tom lane
Re: Test::More version
On 2021-Nov-11, Andrew Dunstan wrote: > But I'd really like it if we could shift the goalposts a bit and require > 0.96. subtests would be really nice to have available. Agreed, subtests would be nice. > Perhaps we could add a line to one of the TAP tests that would spit out > the version on the log? Maybe have it spit out the version of *all* the modules we require (which aren't all that many), not just Test::More? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Test::More version
perldoc Test::More says: Key feature milestones include: subtests Subtests were released in Test::More 0.94, which came with Perl 5.12.0. Subtests did not implicitly call "done_testing()" until 0.96; the first Perl with that fix was Perl 5.14.0 with 0.98. "done_testing()" This was released in Test::More 0.88 and first shipped with Perl in 5.10.1 as part of Test::More 0.92. We actually test for a version >= 0.87 both in PostgreSQL::Test::Utils and in configure.ac. That seems wrong, since we need done_testing(). But I'd really like it if we could shift the goalposts a bit and require 0.96. subtests would be really nice to have available. Unfortunately I don't have any idea what versions of Test::More are actually in use. Perhaps we could add a line to one of the TAP tests that would spit out the version on the log? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
