Re: Why is use_ok failing in this test script?
On Sat, May 17, 2008 at 11:20 AM, Michael G Schwern [EMAIL PROTECTED] wrote:
Andreas J. Koenig wrote:
On Sat, 17 May 2008 07:35:27 -0500 (CDT), David Fleck
[EMAIL PROTECTED] said:
df I hope someone can help out this novice test writer. I have a module
that df runs several test scripts, and recently they have started to fail
on some df tester's machines. The tests work fine for me, and I can't see
anything df in the Test::More documentation that tells me what's going on.
It seems like Test::More broke between 0.74 and 0.78. I've seen the
same pattern on Slay-Makefile-Gress.
Without any further information, all I can do is guess, but this is likely
Test::More not breaking but fixing a bug and revealing a hidden failure.
http://groups.google.com/group/perl.qa/browse_thread/thread/6ce3cc2762ab030c
As referenced by Michael, this was not Test::More that broke. Instead,
it got fixed of the BEGIN { use_ok } bug that ran silently before
planning, silently succeeding whether or not it failed.
This bug had some far reaching impacts because the usage below turned
to be very common:
use Test::More;
plan tests = $num_tests;
BEGIN { use_ok 'Foo' } # this one did not enter the test count
ok(1);
...
As discussed at length, the correct version (which happens to work
with the buggy and fixed Test::Builder) is:
use Test::More;
BEGIN { plan tests = $num_tests; }
BEGIN { use_ok 'Foo' } # now this one should enter the test count
ok(1);
...
Obviously, that bug should never have happened, so that usage would
have been readily flagged as flawed and corrected before distribution
release. But things are not perfect and, as we don't aim for bug
compatibility, the bug got fixed, demanding the minor adjustment of
the flawed code in the wild that relied on this defect.
--
52. Not allowed to yell Take that Cobra at the rifle range.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Versioning modules
Hi, I never had much luck with the Version.pm module. Either because I wasn't in the mood to read the documentation or plain dumb. In any case the versioning scheme X.Y.Z is a non sense. It works nicely for someone not doing version control but for people using one a module version should not be different from what is checked in. SVK had one nice thing for it, the revisions start at 1 and grow upwards. I got fed up SVK bugs so I decided to go over to git. The problem is that git generates SHA1 as commit ids. Something like 37c8bee442237c6ccb7ad1d2cef9c2d3ac7de979 I like to generate a distribution automatically including the version number but I'm afraid the above is going to draw flames. How do you do? Cheers, Nadim.
Re: Versioning modules
On Sun, 18 May 2008, nadim khemir wrote: Something like 37c8bee442237c6ccb7ad1d2cef9c2d3ac7de979 I like to generate a distribution automatically including the version number but I'm afraid the above is going to draw flames. It would draw flames because it would break every damn CPAN tool. The hashed version does not guarantee that successive versions are greater than (Perl's gt) than previous. Whatever you choose has to consistently compare as great than the previous version. One possibility is to use the date as a number, something like '20080518', and maybe even include the time. -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Versioning modules
On Sun, May 18, 2008 at 07:13:17PM +0200, nadim khemir wrote: I like to generate a distribution automatically including the version number VCS identifiers have very little value outside of their context. For example, knowing that you are now on revision 3000 is useless -- it's much more meaningful to know that you've released 2.0, especially if the previous version was (e.g.) 1.7. That's why tags are valuable; they map human-significant identifiers to vcs-significant ones. You might like Perl::Version's perl-reversion program. -bump is for run-of-the-mill releases, -bump-whatever for more major changes. hdp.
