# from David Golden
# on Sunday 09 August 2009 05:25:
>Remember, this is Module::Build saying: "You're too lazy to specify
>what version of me you need, so I guess I have to read your mind or
>come up with some reasonably sane fallback to protect your from
>yourself."
>
>In that context "0" means "you didn't say, so I guess any version will
>do" and "X.YY" means "the last version I know your end users will be
>able to get from CPAN".
>
>The latter version is now in the repo.
This is a good default. Particularly for those of us who are running
trunk.
Adam is right that this might let an alpha-feature requirement slip
through. But if you need an alpha feature, it's actually better to
just have the alpha version in configure_requires -- because users
*can* satisfy the alpha (even if they have to get it from svn) whereas
nobody can satisfy the next-major-version requirement until it ships.
For a less-fiddly automatic setting of configure_requires, we might want
to have a table of named features mapped to version numbers. But I
would still use alpha numbers in that table - just warn the user during
ACTION_dist() if their required feature is in alpha (implied by being a
bigger number than the last major release extracted from the current
$VERSION.) Maybe some pod with '=item' entries under each =head2
$VERSION section could be cooked into a .pm at build time.
--Eric
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
--Donald Knuth
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
