3 packages 1 uniform version

[jonasbn]

I have a problem, which I have somewhat solved, but I am not completely satisfied with the solution since it holds some problems. I have 3 packages defined in separate files, I want these packages to have the same version. My current solution in defining the version in a fourth package:

package PoorMansConfiguration::VERSION;

$VERSION = '1.34';

Which is then used in the 3 other packages:

BEGIN {
use PoorMans::Configuration::VERSION;
$VERSION = $PoorMans::Configuration::VERSION::VERSION;
};

The problem with this solution is that is not easily recognized by version parsing code, like the code used by Module::Build. So is there a better way to solve my problem?

[roboticus]

jonasbn:

You could put an easily-recognized version statement in your modules, and sync them with a perl one-liner. So if your version statement was always in the form:

$VERSION='1.34';

then you could update all your versions to be the same with:

perl -pi -e 's/^$VERSION='\d\.\d\d';/$VERSION='2.56';/' foo.pl

...roboticus

[jonasbn]

You gave me a marvelous idea, the updating of the version number is now a part of the distribution building. Thanks for the suggestion, you got me thinking outside the box.

[Anonymous Monk]

I do this in all my packages: Create a VERSION.pm containing the following code:

package Foo::VERSION;
$VERSION=(qw$Revision: 1.119 $)[1];

Which is updated by cvs everytime I check the package in. In each subpackage I have the following line:

$VERSION = eval { require Foo::VERSION; do $INC{'Foo/VERSION.pm'}};

Must be all on one line if you want it interpreted by CPAN etc.

[samtregar]

I usually just leave out versions for subordinate packages. For example, XML::Validator::Schema has a VERSION but XML::Validator::Schema::Parser does not. Is there a reason you need all the packages to have versions?

-sam

[jonasbn]

Well yes, it is a poor mans configuration management system. So we have a package for each sort of environment we have (dev, test, prod). So the files are versioned as the same version agnostic to the actual environment context they are used in and we can specify the version as a requirement in the actual applications.

[proceng]

You did not note what platform... Subversion, CVS and RCS are all good (free) candidates for revision control, with the bonus that each will allow you to add a description of changes and revert to an earlier version if necessary. That way you can check out v1.01 for development (or use a tree setup where v1.0.x is dev, 1.1.x is test, 1.2.x is prod) so that you only have one directory tree to backup/maintain. YMMV ;-)