VERSION comparisons in universal.c, CPAN, and ExtUtils, was Re: CPANand module VERSION numbers generated from CVS/RCS

On Thu, 26 Jul 2001, Greg Bossert wrote:

> From: Greg Bossert <bossert@fuaim.com>
> To: perl5-porters@perl.org
> Newsgroups: comp.lang.perl.modules
> Date: Thu, 26 Jul 2001 01:25:01 -0700
> Subject: Re: CPAN and module VERSION numbers generated from CVS/RCS
>
> I had just been looking at CPAN::Version in some frustration when I noticed David's
> post.  The reponses in comp.lang.perl.modules do suggest some approaches to making
> the CPAN code more flexible.  However, it looks to me like there are two issues:
> (1) a cross-Perl policy for module version numbering, documented consistently and
> (2) a consistent code base across the various tools that refer to module versions
> (e.g. ExtUtils and CPAN).
>
> I don't see any reason why policy needs to conform to the functionality of RCS et
> al; code like that quoted by David from perlmod is easy enough to include in new
> modules.  Matter of fact, it's not clear to me that the policy needs to be all that
> strict, though it would be helpful, IMHO, for the CPAN FAQ and the perlmod POD to
> give some standard for number of dots (2 like most current modules? 3 like Perl
> itself?) and number of digits.
>
> Regardless of the policy, the code to handle the versions ought to be liberal in
> its interpretation, both for transition purposes and to allow for human nature, as
> it were.   I propose that the algorithm should be to compare each segment (i.e.
> sequence of digits separated by dots) as integers, moving from left to right,
> appending "0" segments as needed (e.g. in cases like 4.2.3 vs. 4.2, the latter
> becomes 4.2.0).
>
> Whatever the decision here is, I'd argue that CPAN::Version::vcmp is incorrect, in
> that, unless there are leading "v" characters, it will compare two complete version
> strings as numbers or as strings:
>
>   return
>       ($l ne "undef") <=> ($r ne "undef") ||
>           ($] >= 5.006 &&
>            $l =~ /^v/ &&
>            $r =~ /^v/ &&
>            $self->vstring($l) cmp $self->vstring($r)) ||
>                $l <=> $r ||
>                    $l cmp $r;


Greg mentions that CPAN::Version::vcmp is incorrect, but
I've since learned that there is even 'stranger' version
comparisons going on in universal.c
for the used of UNIVERSAL::VERSION.

I think that the use of UNIVERSAL::VERSION
to assist with version comparisons when
loading modules is not documented anywhere
other than reading the sources.

Perl_utilize
Perl_vload_module
and perly.c

use     :       USE startsub
                        { CvSPECIAL_on(PL_compcv); /* It's a BEGIN {} */ }
                    WORD WORD listexpr ';'
                        { utilize($1, $2, $4, $5, $6); }
        ;

My reading of "perldoc -f use" led me to think that the import
function was checking for the required version, I didn't realized
that there was core/builtin support to do the version compare.

   David

> This is what is generating the error David cited with DBI::DBD, and had me
> frustrated earlier today.
>
> Finally, clever use of pack aside, the CPAN::Version code seems, IMHO,  needlessly
> complex; a strategy of always converting to a canonical form would be simpler and
> more useful in other contexts.  Depending on discussion here, I may sumbit this as
> a bug with some simple substitute code;  however, I prefer Ed Avis' suggestion of
> using Sort::Versions or something similar as a standard code base.  If it's going
> to be used in ExtUtils and CPAN, the new code would of course have to be in the
> standard distribution.
>
> The problem may not seem like a big deal, but it is quite an inconvenience to
> anyone trying to automate some of the module installation and maintenance process,
> let alone someone trying to figure out what version string to create for a new
> module.
>
> -g
>
> David Dyck wrote:
>
> > ( I directed this to comp.lang.perl.modules as well as p5p)
> >
> > I'd like to start a discussion on what the best
> > way to use VERSION numbers numbers that are generated
> > from RCS or CVS Revision numbers and how get CPAN to compare
> > them better.  (the problem seems to arise when the new revision
> > number has more digits than the earlier version).
> >
> > perldoc perlmod suggests the following example
> >    $VERSION = do { my @r = (q$Revision: 2.21 $ =~ /\d+/g);
> >         sprintf " %d."."%02d" x $#r, @r }; # must be all one line, for MakeMaker
> >
> > This might fix the problem that I am seeing from
> >  /usr/local/bin/perl -e 'use CPAN; CPAN::Shell->r;'
> >
> > where
> > /usr/local/bin/perl -e 'use CPAN; CPAN::Shell->r;'
> > Package namespace         installed    latest  in CPAN file
> > DBI::DBD                      10.10      10.9  T/TI/TIMB/DBI-1.18.tar.gz
> >
> > by converting the 10.9 to 10.09, but it doesn't fix the case
> > when the version is bumped from 10.99 to 10.100.
> > The problem of changing the number of digits in the
> > version string still exists.
> >
> > I am also surprised that perlmod suggest only 2 digits, but
> > some of the code in CPAN seem to suggest 3 digit version numbers.
> > (perlmodlib suggests "at least two digits", and to not
> >  use a "1.3.2" style version.  Exporter also suggests using versions
> >  numbers with at least 2 decimal places if you use the default require_version)
> >
> > I looked into ExtUtils::MM_Unix::parse_version
> >  (pulled in from ExtUtils::MakeMaker)
> > as well as
> >     CPAN::Version::vcmp,
> >     CPAN::Version::vgt,
> >         # vgt says "v10.10" > "v10.9, and v10.10 > v10.9
> >     CPAN::Version::vstring,
> >         # I like how vstring uses pack "U*", split /\./, $n;
> >         #  to extract a version number "v10.9" in a string
> >         #  into a v10.9 unicode character v-number.
> >
> > It looks like CPAN's CPAN::Shell->r would handle
> > "v10.9" and "v10.10" and not report that version 10.9
> > was newer that version 10.10, but just how far should
> > a module author have to go.  I'm not sure how
> > compatible this would be with the Exporter module.
> >
> > Also, while CPAN goes to the trouble to deal with
> > version strings beginning with "v", Exporter::require_version only does
> > a numeric conversion.
> >
> > I'd like to here thoughts on how this inconsistency
> > could be resolved, and again, how to work best with
> > VERSION strings that are derived from RCS/CVS Revisions numbers.
> >
> > Thanks,
> >   David Dyck
>
>
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
>

• VERSION comparisons in universal.c, CPAN, and ExtUtils, was Re: CPANand module VERSION numbers generated from CVS/RCS by David Dyck