Greets,
Most Apache projects seem to use X.Y.Z version numbering. Specifying X.Y.Z
versions in Perl is messy, though, as David Golden explains:
http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
I think we'd be better off if we avoided vstrings and version.pm objects.
But then, specifying X.Y.Z versions in C isn't straightforward either --
there's no native C vstring type, after all. A lot of projects (Perl, GCC,
Subversion, etc) use 3 or more integers to convey version information
programatically.
For my CPAN distros, I've always had all version number formats match exactly
in all of the following places:
* Distribution archive name => KinoSearch-0.31.tar.gz
* Documentation (POD, Changes, README, etc.) => 0.31
* META.yml => 0.31
* $VERSION => "0.31"
However, research has revealed that it's not mandatory for all formats to
match. See this comment from Darren Duncan:
http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/#comment-2746
For the last few years, the practice I have followed for the modules I
write is to use X.Y.Z version numbers conceptually and in my documentation
and as my distro version, and I use the corresponding X.00Y00Z versions in
the actual code of my modules for declaration and use.
One example of a distro where version numbers are expressed differently in
different contexts is Apache's Mail::SpamAssassin.
Dist archive name => Mail-SpamAssassin-3.3.1.tar.gz
Documentation => 3.3.1
META.yml => 3.003001
$VERSION => "3.003001"
Note that SpamAssasin used the floating point variant in META.yml. I'd be
inclined to use the X.Y.Z format there, as Duncan does for his distro
Set::Relation.
Dist archive name => Set-Relation-0.12.7.tar.gz
Documentation => 0.12.7
META.yml => 0.12.7
$VERSION => "0.012007"
Based on these precedents, I believe it's technically feasible to use X.Y.Z
versioning for Lucy and it's Perl bindings:
Dist archive name => Lucy-0.1.0-incubating.tar.gz
Documentation => 0.1.0
META.yml => 0.1.0
$VERSION => "0.001000"
Other host binding languages will present similar challenges when expressing
X.Y.Z version information programmatically; presumably, similar workarounds
will be found for all of them.
Marvin Humphrey
