# from Michael G Schwern # on Friday 19 February 2010 16:45: >> Is *not* using version.pm an option? > >For once, I really need x.y.z versions. >http://search.cpan.org/~mschwern/perl5i-v0.2.2/lib/perl5i.pm#VERSIONING
I'll continue to hold the opinion that vX.Y.Z versions don't strictly require version.pm, but you may use it if you like. :-D But for addressing your actual issue... >>> use perl5i::VERSION; our $VERSION = perl5i::VERSION->VERSION; >>>Unfortunately when Build.PL is reading the version it picks up the >>>installed perl5i::VERSION and not the one sitting in lib. >>>A simple fix would seem to be putting "use lib 'lib'" into the >>>Build.PL. Any caveats. Alternatively, anyone have a better way? You're going to be swimming upstream against the tools with that, plus it lacks the redundant robustness of simply sticking a number in every file. The drawback of SANIEF is you (developer) have to run something before and/or after each release and commit -m "bumped the version to $new_version". The benefit of SANIEF is that users (or you (or your code, even)) can more easily tell when their install is botched, plus opening any file in the project puts a number right in front of you. I suggest you do something with perl-reversion, and optionally look at how we do it (devtools/bump_version.pl and the bottom of this pod.) https://svn.perl.org/modules/Module-Build/trunk/devtools/release_instructions.pod . o O (What a nifty plugin that would make.) Another (orthogonal) thought: bump the version before *and* after you release, so "trunk" between releases is a gray area: you can require that version, but requiring a trunk version never satisfies a later tagged+released version. --Eric -- Minimum wage help gives you minimum service. --David Schomer --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
