Re: Proper technique for setting a project-wide $VERSION?

# 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
---------------------------------------------------