On Wed, January 9, 2013 9:03 pm, David Christensen wrote:
>
> There seems to be two competing points of view regarding version
> numbering for software source code files:
>
> 1. Per-file -- a unique version number for each file that increments
> when that file changes. RCS and CVS use this approach. They also
> provide keywords that can be embedded in files for accessing version
> control system meta-data. For example, I use CVS and embedded it's
> "$Revision$" keyword in my Perl files with the following incantation to
> set the Perl $VERSION variable:
>
> our $VERSION = sprintf "%d.%03d", q$Revision: 1.32 $ =~ /(\d+)/g;
>
> http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_12.html#SEC99
>
> 2. Per-set -- unique version number for a set of files that increments
> when any one of them changes (and is the same for all the files in the
> set). I believe Subversion and Git use this approach (and Mercurial?).
>
Yeah, after dithering about it for a few days, I went with the philosophy
that the package has the version, not the individual modules. For the
simple reason that the package as a whole is what's being developed, from
the documentation to the scripts to the README file to, of course, the
actual modules themselves.
Hmm. I use the 'dist_version' key in my Build.PL file. Maybe I can take
Gabor's idea and update my $VERSION values automatically using Build.PL as
the starting point. This would maintain the "holistic" approach, and give
me a single file to update instead of worrying about every file with a
version number (which for me would be the README file and any *.pm files
under the lib directory).
>
> Perhaps Gabor should consider using the second type of version control
> system that allows a Perl incantation similar to the first.
>
Except that PAUSE (which is the primary driver of the $VERSION use) wouldn't
be able to make use of it. As far as I can tell, it loads the .pm files to
find the $VERSION number, and doesn't look at META.json at all.
-john
