$VERSION diversion

polettix has asked for the wisdom of the Perl Monks concerning the following question:

Writing a couple of scripts, I eventually got to the point to use a script-starter template much in the spirit of Module::Starter. In an effort to get things done as much cleanly as possible, I obviously included a starter boilerplate for documentation, with some basic sections like NAME, DESCRIPTION and... VERSION.

On the other hand, I also borrowed the use of the $VERSION variable from the module world:

use version; my $VERSION = qv( '0.0.1' );
[download]

Argh! Now I've to update the VERSION in two places! What's worst, this happens with modules as well, even if this kinda bothers me less because I'm not that module creator :)

Regarding scripts, I'm leaning towards eliminating the $VERSION variable, just because I seem to use it as a result of some sneaky form of cargo cult. Before I do this, anyway, I'd like to hear comments. Regarding modules, I understand the need for $VERSION, but then the double-VERSION problems strikes back.

How do you address this problem?

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

Comment on $VERSION diversion Select or Download Code

Replies are listed 'Best First'.
Re: $VERSION diversion by Herkum (Parson) on May 02, 2006 at 13:51 UTC
I understand what you mean, it is difficult to manage the VERSION variable between multiple scripts and modules in the same distribution. Mainly because it feels like additional busy work. I do view it this way and it helps me focus on why I try to keep the version updated. Updating documentation. I will forget to update the version information in my Pod even though I updated the version for a module. It forces me to think about what I just did and go back and check my Pod for changes, not just blindly update the version everywhere. Especially when the Pod version is 1.01 and the module version 1.11. I have to think "What do I update that makes this application a more current version?" Debugging. I forget to update the version in all my modules in a distribution, I will wonder "where did this file come from? Is old or is part of the current version?" I find it is easier to update the version for all my modules in a distribution rather just update the one file that is used in Build.PL or just using dist_version parameter.	[reply]
Re: $VERSION diversion by tinita (Parson) on May 02, 2006 at 22:09 UTC
edit: this seems to work much better than my original idea: `our $VERSION; my $version_pod = <<"=cut"; =pod =head1 NAME blah blah =head1 VERSION @{[ $VERSION = "0.23" ]} =cut` [download] update: any ideas how to get the `@{[]}` stuff out with `=for comment`? here my original idea: Read more... (2 kB)	[reply] [d/l] [select]
Re: $VERSION diversion by polettix (Vicar) on Jul 27, 2006 at 09:46 UTC
Update: Alas, Aristotle had already written a meditation about this! Aristotle has elaborated a cool hack here on use.perl.org, I hope not to infring any copyright duplicating it here: `eval "package Some::Module; $_" for grep m/ = /, split /\n/, <<'=cut'; =head1 VERSION =for fooling makemaker =cut-feigned This document describes Some::Module, $VERSION = 0.1 =cut` [download] that yields: `$ perldoc ./Some/Module.pm \| grep VERSION This document describes Some::Module, $VERSION = 0.1 $ perl -MSome::Module \ -le'print Some::Module->VERSION' 0.1 $ perl -MExtUtils::MakeMaker \ -le'print MM->parse_version(shift)' Some/Module.pm 0.1` [download] Wow, the road to the Dark Side of the Perl is surely attractive! Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply] [d/l] [select]