On Sep 11, 2009, at 8:08 PM, Jonathan Swartz wrote:
What's a good policy for setting $VERSION in the non-"main" modules
of a distribution?
e.g. I've got Server-Control-0.08, and Server::Control contains
our $VERSION = '0.08';
but none of the other modules in the distribution (e.g.
Server::Control::Apache) contain a $VERSION. I can see at least
three possibilities:
1) Don't bother putting $VERSION anywhere except the main module
2) Put a different $VERSION in each module, depending on when that
module itself changes
3) Put the same $VERSION in each module, matching the distribution
and the main module
1 clearly wins for laziness - is there a reason to do more? If so,
pros/cons to 2 vs 3?
Thanks
Jon
I always choose #3.
If you don't put a $VERSION in a sub-module, then it's hard for an
arbitrary user to tell if he has a corrupt installation with mixed
versions. Consider the case where you rename Server::Control::Apache
to Server::Control::Plugin::Apache between version 0.08 and 0.09.
Then a user who sees Server/Control/Apache.pm with $VERSION = 0.08
knows that that is an obsolete file in contrast to Server/Control.pm
with $VERSION = 0.09.
With automated build tools (e.g. "perl -i -pe's/\$VERSION = 0.08/\
$VERSION = 0.09/' lib/{,*/,*/*/}*.pm") it's trivial to update the
version number of the whole group of modules at once. The biggest con
is churn -- even if you don't change any of the code Server/Control/
Apache.pm, you still must commit another SVN/Git/etc version of it
just because the version number changed. That makes it harder to read
the version control logs. The best practice to mitigate this is make
the version number change be a single commit with no other changes.
That way, the version change doesn't bury small code changes. This
churn also adds a little noise to the diff tool on search.cpan.org.
Chris
