Обсуждение: 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
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/
Alvaro Herrera <alvherre@alvh.no-ip.org> 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
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.
On 11/11/21 15:44, Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> 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
Вложения
Andrew Dunstan <andrew@dunslane.net> 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
Peter Eisentraut <peter.eisentraut@enterprisedb.com> 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
On 11/12/21 10:05, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> 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
Andrew Dunstan <andrew@dunslane.net> 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
Tom Lane <tgl@sss.pgh.pa.us> 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.0 0.72 v5.10.1 0.92 v5.12.0 0.94 v5.14.0 0.98 v5.16.0 0.98 v5.18.0 0.98 v5.20.0 1.001002 v5.22.0 1.001014 v5.24.0 1.001014 v5.26.0 1.302073 v5.28.0 1.302133 v5.30.0 1.302162 v5.32.0 1.302175 v5.34.0 1.302183 - ilmari
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> Tom Lane <tgl@sss.pgh.pa.us> 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.0 0.94
> v5.14.0 0.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
Tom Lane <tgl@sss.pgh.pa.us> writes: > =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes: Your MUA seems a bit MIME-deficient… >> Tom Lane <tgl@sss.pgh.pa.us> 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.0 0.94 >> v5.14.0 0.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
On 11/15/21 14:14, Tom Lane wrote: > =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes: >> Tom Lane <tgl@sss.pgh.pa.us> 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.0 0.94 >> v5.14.0 0.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
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
Andrew Dunstan <andrew@dunslane.net> 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
On 11/20/21 11:14, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> 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